Flow label based traffic scheduling method, device and equipment

Abstract

The application discloses a flow label-based traffic scheduling method, device and equipment. The method comprises the following steps: a source computing node divides the service flow in a single RDMA queue pair into multiple independent sub-flows based on a preset semantic boundary; the source computing node generates an IPv6 flow label for each sub-flow, and fills the IPv6 flow label into the corresponding field of an IPv6 header when encapsulating a data packet; and the source computing node and / or a network node schedules the data packets of different sub-flows to different network paths for transmission based on the IPv6 flow label in a path selection process. The application can greatly improve the traffic entropy of the network by performing semantic subdivision on the service flow in the queue pair, dividing the service flow into multiple independent sub-flows, and allocating different IPv6 flow labels to each sub-flow, so that the elephant flow can be transmitted through multiple paths, and the out-of-order problem caused by the multi-path transmission can be avoided by using the intermittent characteristics of the traffic.

Description

Technical Field

[0001] This application relates to the field of computer network technology, and more specifically, to a flow label-based traffic scheduling method, apparatus, and device. Background Technology

[0002] In large-scale AI training, high-performance computing, and scientific simulation scenarios, hundreds to thousands of computing nodes within a cluster need to frequently exchange model gradients, parameter shards, and other data. To meet the requirements of low latency, high bandwidth, and low CPU usage, current mainstream systems generally adopt high-performance networks based on RDMA (Remote Direct Memory Access) technology. The communication mode of such clusters is centered on collective communication primitives, undertaking key functions such as parameter synchronization and gradient aggregation. However, RDMA traffic in workloads has the following typical characteristics in terms of time dimension and traffic structure: communication is significantly intermittent; there is a long-term phenomenon of "elephant streams"; and the overall network traffic entropy is extremely low.

[0003] The intermittent, long-term, and low-entropy characteristics of RDMA traffic in clusters make it difficult for traditional static load balancing strategies based on IP 5-tuples to achieve effective path utilization, easily leading to link congestion, resource waste, and degraded training performance. How to achieve dynamic scheduling and load balancing of long-term RDMA traffic without altering the semantics of RDMA communication has become a significant technical challenge in AI network architecture. Summary of the Invention

[0004] This application provides a flow tag-based traffic scheduling method, apparatus, and device to at least solve the technical problems of difficulty in achieving multi-path traffic scheduling and load balancing in related technologies.

[0005] According to one aspect of the embodiments of this application, a traffic scheduling method based on flow labels is provided, comprising: Based on preset semantic boundaries, the source computing node divides the service flow within a single RDMA queue pair connection into multiple independent sub-flows; The source compute node generates an IPv6 flow label for each sub-flow and fills it into the corresponding field of the IPv6 header when encapsulating the data packet; During the path selection process, the source computing node and / or network node schedules data packets of different sub-streams to different network paths for transmission based on the IPv6 flow labels.

[0006] In one implementation, the source computing node divides the service flow within a single RDMA queue pair connection into multiple independent sub-flows based on preset semantic boundaries, including: Based on collective communication semantic boundaries, the service flow within a single RDMA queue connection is divided into multiple independent sub-flows; or, Based on the semantic boundaries of the algorithm steps, the service flow within a single RDMA queue pair connection is divided into multiple independent sub-flows; or, Based on the semantic boundaries of data blocks, the service flow within a single RDMA queue connection is divided into multiple independent sub-flows.

[0007] In one implementation, the source compute node generates IPv6 flow labels for each subflow, including: The source computing node, in conjunction with a preset perturbation factor, uses an unpredictable random number generator to generate an approximately uniformly distributed random value; the perturbation factor includes a timestamp, a session identifier, and a queue pair initialization seed; The random value is used as the IPv6 flow label for the sub-flow.

[0008] In one implementation, the source compute node generates IPv6 flow labels for each subflow, including: The source computing node performs cryptographic hashing on preset semantic parameters to obtain the output of the hash function. The semantic parameters include queue pair identifier, collective communication primitive type, and message sequence number. The IPv6 flow label is obtained based on the output of the hash function.

[0009] In one implementation, the source compute node generates IPv6 flow labels for each subflow, including: The source computing node obtains identification information from different semantics, including queue pair identifiers, collective communication primitive identifiers, algorithm step identifiers, message sequence numbers, and time slice numbers; The identification information is XORed with a random initial value to obtain the result. The IPv6 flow label is obtained based on the calculation result.

[0010] In one implementation, the source compute node generates IPv6 flow labels for each subflow, including: The source compute node randomly generates an initial stream label for the first sub-stream within the queue pair; The IPv6 flow labels for subsequent sub-flows are generated using an incremental random number method, and the flow labels for the subsequent sub-flows are incremented by a fixed step size based on the initial flow label.

[0011] In one implementation, during path selection, the source computing node schedules data packets from different sub-flows to different network paths for transmission based on the IPv6 flow labels, including: The source computing node calculates the scheduling weight of each network plane based on the available bandwidth of each network plane fed back by the RDMA flow control protocol. Based on the scheduling weights and combined with the IPv6 flow labels assigned to each sub-flow, the data packets of the different sub-flows are distributed to the corresponding network planes for transmission.

[0012] In one implementation, during path selection, network nodes, based on the IPv6 flow labels, schedule data packets from different sub-flows to different network paths for transmission, including: Network nodes obtain triplet information based on the IPv6 flow label, source IP address, and destination IP address of the subflow; Perform a hash operation on the triplet information to generate a corresponding hash key value; Network nodes dynamically determine the scheduling weight of each candidate path based on local link information or end-to-end path information; Based on the hash key and the scheduling weight, data packets from different sub-streams are distributed to the corresponding network paths for transmission.

[0013] According to another aspect of the embodiments of this application, a flow tag-based traffic scheduling device is also provided, comprising: The sub-stream partitioning module is used by the source computing node to divide the service flow within a single RDMA queue pair connection into multiple independent sub-streams based on preset semantic boundaries. The sub-flow identification module is used by the source compute node to generate IPv6 flow labels for each sub-flow and fill them into the corresponding fields of the IPv6 header when encapsulating data packets; The traffic scheduling module is used by the source computing node and / or network node to schedule data packets of different sub-flows to different network paths for transmission based on the IPv6 flow labels during the path selection process.

[0014] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the above-described flow tag-based traffic scheduling method through the computer program.

[0015] The technical solutions provided in this application embodiment may include the following beneficial effects: This application's source compute node, based on preset semantic boundaries, divides the service flow within a single RDMA queue pair connection into multiple independent sub-flows. An IPv6 flow label is generated for each sub-flow. During path selection, the source compute node and / or network node, based on the IPv6 flow label, schedule data packets from different sub-flows to different network paths for transmission. This application's scheme, while maintaining the end-to-end ordering semantics and congestion control mechanism of the RDMA queue pair connection, semantically subdivides the service flow within the queue pair, dividing it into multiple independent sub-flows and assigning different IPv6 flow labels to each sub-flow. This significantly increases network traffic entropy, allowing large flows to be transmitted via multiple paths. It also effectively avoids out-of-order multi-path issues by utilizing the intermittent nature of traffic, thereby achieving finer-grained and fairer network scheduling and load balancing, significantly improving network throughput and resource utilization. Attached Figure Description

[0016] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart of a flow tag-based traffic scheduling method according to an embodiment of this application; Figure 2 This is a schematic diagram of an intermittent collective communication operation in a training step according to an embodiment of this application; Figure 3 This is a schematic diagram of one operation step according to an embodiment of this application; Figure 4 This is a schematic diagram of multi-plane traffic scheduling based on flow tags according to an embodiment of this application; Figure 5 This is a schematic diagram of a flow tag-based traffic scheduling device according to an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0017] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0018] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0019] The flow label-based traffic scheduling method of this application, as described below with reference to the accompanying drawings, will be described in detail. Figure 1 As shown, the method mainly includes the following steps: Based on preset semantic boundaries, the S101 source computing node divides the service flow within a single RDMA queue connection into multiple independent sub-flows.

[0020] In this context, the source computing node refers to the computing device that initiates and sends data communication requests in a distributed computing system, such as an AI training cluster or a high-performance computing cluster. It is both the entity that performs the computing task and the starting point of the network data flow.

[0021] In AI training and high-performance computing tasks, the RDMA QP (QueuePair) established between two computing nodes typically remains unchanged throughout the task cycle, and multiple messages are transmitted through this queue pair. These messages are used to complete Collective communication primitives or other RDMA operations. Due to the periodicity of the "computation-communication-computation" phase in parallel computing, there are often significant idle intervals between communication phases, ranging from tens of milliseconds to hundreds of milliseconds or even longer. These time-independent communication phases can naturally form multiple substreams.

[0022] Traditional stream segmentation is a passive, implicit segmentation based on the transmission interval or idle time of data packets on the physical link. Its generation depends on the instantaneous fluctuations in network congestion or transmission rate, and is therefore uncertain. In contrast, the sub-stream generation in this application is entirely determined by RDMA communication semantics, and is deterministic.

[0023] Each sub-stream semantically corresponds to a continuous RDMA operation, thus possessing a clear semantic boundary. However, the division of stream segments is typically based on idle time settings on the switch, which are semantically unrelated. Improper settings can still lead to out-of-order data packets. Furthermore, the time intervals between sub-streams are significantly longer (milliseconds), far exceeding the microsecond timescale of stream segments.

[0024] Based on these characteristics, RDMA application layers, such as collective communication libraries, can identify these semantic boundaries and attach different IPv6 flow labels to each sub-flow when generating RDMA packets. In this way, network nodes can allocate different sub-flows to different paths based on the flow labels during scheduling, achieving finer-grained and more uniform load distribution without altering the reliability and ordered transmission mechanisms of RDMA itself.

[0025] According to IETF standards, the Flow Label field (20 bits) in the IPv6 header is set by the source node to identify the traffic category. Its encoding method is unrestricted and can be freely defined by the upper layer. Network devices exhibit good flexibility and consistency when performing load balancing based on flow labels, without affecting other fields such as IP addresses and UDP ports, making network behavior predictable and controllable. Other IP header information, such as UDP source / destination ports bound to queue pairs, cannot be changed within a long-lived queue connection and cannot be used as sub-flow identifiers.

[0026] In the embodiments of this application, the RDMA upper-layer application can define sub-flows based on the following different semantic boundaries and assign them different IPv6 flow labels. The source computing node serves as the hardware carrier, on which the RDMA upper-layer application runs.

[0027] Optionally, based on collective communication semantic boundaries, the service flow within a single RDMA queue connection can be divided into multiple independent sub-flows.

[0028] In distributed AI training and high-performance computing, each collective communication (e.g., AllReduce, AllGather, ReduceScatter, etc.) semantically constitutes a complete and independent synchronous communication process. A collective communication typically corresponds to the aggregation of model parameters or gradients, and all nodes are in a strictly synchronized state during its execution. However, due to the existence of computation phases, the communication behavior between different collective communications is significantly intermittent, with time intervals often reaching tens or even hundreds of milliseconds. In the underlying implementation of RDMA, these collective communications reuse the same queue pair connections, causing the data packets of all collective communications to be regarded as the same "elephant stream" in the network, making it impossible to effectively utilize multi-path load balancing resources.

[0029] Based on this, this application treats each collective communication as a semantically independent sub-flow. A new flow label is generated by the upper-layer communication library upon entering a collective communication, and this new label is used at the start of the next collective communication. In this way, all RDMA messages within the same collective communication share the same flow label, while different collective communications use different flow labels. This allows the network to identify semantic boundaries at the collective communication level and schedule them independently, thereby significantly improving network path utilization and overall fairness.

[0030] like Figure 2 As shown, this illustrates the flow composition during a training process that simultaneously employs tensor parallelism (TP), data parallelism (DP), and pipeline parallelism (PP). Each "pillar" represents a collective communication session, with distinct time intervals between them, allowing for the division into different sub-flows and assigning them different flow labels.

[0031] Optionally, based on the semantic boundaries of the algorithm steps, the service flow within a single RDMA queue connection can be divided into multiple independent sub-flows.

[0032] In many high-performance collective communication implementations, a large collective communication operation is broken down into multiple sequentially executed algorithmic steps. Each step processes only a portion of the data, transmits the intermediate results down the communication topology to the next node, and performs a computation on the portion of the results received from the previous node. Only after the data reception and computation of a certain step are completed does the algorithm proceed to the next step, thus gradually completing the entire collective communication.

[0033] like Figure 3 As shown, taking a circular full reduction operation with four GPUs as an example, in step 1, GPUi passes its data Di to GPU (i+1 mod 4) in a clockwise direction, and then each GPU performs a reduction operation once. In step 2, GPUi passes the previously reduced data to the next GPU in a clockwise direction. Step 3, and so on, completes the entire operation. Due to communication and the execution of the reduction operation, these three steps typically take tens to hundreds of microseconds, forming natural segments in time with clear semantics. They can be regarded as different sub-streams and can be assigned different stream labels.

[0034] Therefore, this application treats different algorithm steps as semantically independent sub-flows, assigning different IPv6 flow labels to each algorithm step. This enables the network to perform fine-grained path scheduling at the step level without altering the reliability and order semantics of the underlying RDMA queue pairs. Due to the approximation on the time scale, this method can, to some extent, replace flow segmentation techniques.

[0035] Optionally, based on the semantic boundaries of data blocks, the service flow within a single RDMA queue pair connection can be divided into multiple independent sub-flows.

[0036] Treating different data blocks as distinct semantic sub-streams and assigning each data block an independent flow label allows them to be transmitted through different paths in the network, achieving a traffic parallelization effect similar to multi-queue pairs while avoiding their structural drawbacks. Since data blocks are application-layer semantically independent data units, there are no order constraints required by the RDMA protocol; therefore, reordering data blocks does not affect the reliability and order guarantees of the RDMA reliable connection model.

[0037] Specifically, RDMA reliable connection mode only guarantees strict ordering of data packets within the same work queue element, without requiring protocol-level ordering between different data blocks. Therefore, using different flow labels only results in different completion times of data blocks at the application layer, without causing out-of-order packets or triggering RDMA retransmissions or queue pair errors. The upper-layer communication library itself has a mechanism to handle different data block orders, allowing for data block reassembly at the receiving end to ensure the correctness of the final result.

[0038] Furthermore, while queue pairs are relatively scarce resources, flow tags are not scarce for upper-layer communication libraries. For the same queue pair, more flow tags can be used to divide the data into more data blocks, enabling parallel transmission. Flow tags do not consume additional resources for hash scheduling by switches and network cards. According to Meta's research and practice on queue pair size and network utilization, the larger the number of sub-flows, the higher the network utilization. Mathematically, further improving scheduling uniformity requires more sub-flows, thus providing higher traffic entropy for multi-path load balancing. The effective entropy growth of random mapping load balancing follows a logarithmic law, i.e.: Where F is the number of substreams.

[0039] Understandably, the number of sub-flows needs to grow exponentially to linearly improve load balancing performance. This application uses flow labels, which, compared to multi-queue pair schemes, can expand a single queue pair to more sub-flows, achieving this exponential growth requirement and thus improving network resource utilization.

[0040] In addition to the three semantics mentioned above, applications or communication libraries can also set flow labels based on other RDMA semantics with well-defined boundaries. As long as such semantic division ensures that different sub-flows are independent of each other and does not introduce out-of-order delivery at the packet level, thus not affecting the reliable connection requirements of RDMA on the same queue pair, it can be used in the method of this application.

[0041] The S102 source compute node generates an IPv6 flow label for each sub-flow and fills it into the corresponding field of the IPv6 header when encapsulating data packets.

[0042] In this application, the source node needs to generate different IPv6 flow labels for each sub-flow, while the network node needs to perform hash calculations based on the flow labels to achieve multi-path scheduling and load balancing. However, it is important to note that the method of generating flow labels has a significant impact on the overall scheduling effect. If the flow labels are generated using a pseudo-random algorithm based on linear congruence or modulo a fixed large prime number, the generated flow label sequence, although theoretically uniformly distributed, still retains a clear modulo structure. Most commercial switches currently use modulo operations when performing equivalent multipath or flow hash load balancing. When the flow label generation space aligns with or forms an arithmetic congruence relationship with the modulo space of the network node's hash function, the bucket result obtained by the network node after hash calculation will be highly skewed. For example, when both the source and network nodes use modulo P or its multiples / subgroup structures, different flow labels are likely to be folded into the same hash interval, resulting in a large number of sub-flows being mapped to the same path or a small number of paths, failing to achieve the expected load balancing effect.

[0043] Therefore, this application requires that the flow label generation logic of the source computing node and the path selection hash logic of the network node be mathematically decoupled. By introducing nonlinear perturbations or high-entropy randomness at the source end, the arithmetic alignment that may exist between the source-side generation space and the network-side mapping space is broken, thereby avoiding hash collisions and path polarization.

[0044] In one optional implementation, the source computing node generates an IPv6 flow label for each subflow, including the source computing node combining a preset perturbation factor with an unpredictable random number generator to generate an approximately uniformly distributed random value; the perturbation factor includes a timestamp, a session identifier, and a queue pair initialization seed; and the random value is used as the IPv6 flow label for the subflow.

[0045] Specifically, the source computing node can employ an unpredictable random number generator, such as the hardware random number generator HRNG, or a high-quality pseudo-random algorithm like MersenneTwister, Xorshift, or PCG, to generate an approximately uniformly distributed random value within the 20-bit space of the IPv6 flow label, and use this random value as the flow label for the sub-flow. Since the generation of random numbers does not depend on a fixed linear modulus structure, nor does it have a predictable arithmetic relationship with the modulo parameters of the hash module on the network node side, it effectively avoids structural alignment between the flow label and the network node's hash bucket. By uniformly distributing the flow label throughout the 20-bit space, this method ensures that the input space of different sub-flows entering the network node's hash function is sufficiently randomized, thereby significantly reducing the probability of hash collisions and improving the randomness and fairness of multipath scheduling.

[0046] Optionally, the random number generation process can incorporate perturbation factors such as timestamps, session identifiers, and queue initialization seeds to further enhance unpredictability. The specific perturbation factors are not limited in the embodiments of this application.

[0047] In one optional implementation, the source computing node generates an IPv6 flow label for each sub-flow, including the source computing node performing cryptographic hashing on preset semantic parameters to obtain the output of a hash function. The semantic parameters include queue pair identifier, collective communication primitive type, and message sequence number. Based on the output of the hash function, the IPv6 flow label is obtained.

[0048] Specifically, the source computing node can generate stream labels by performing cryptographic hashing on specific semantic parameters, such as queue pair identifiers, collective communication primitive types, and message sequence numbers. Hash functions with good uniformity and low skewness, such as SipHash, BLAKE3, or xxHash, are preferred. For example:

[0049] The output of the hash function is truncated to 20 bits and filled into the IPv6 flow label field. This type of cryptographic hash function has strong obfuscation properties; that is, any tiny change in the input will cause the output space to be uniformly distributed, making it difficult to form biased or periodic patterns. Therefore, this method effectively avoids predictable correlations between flow labels and network node hash functions, ensuring that the hash bucket allocation of different sub-flows in network nodes has thoroughly random and high-entropy characteristics.

[0050] Compared to ordinary pseudo-random methods, cryptographic hashing can automatically generate stable but unpredictable stream labels based on the semantic attributes of substreams without exposing the internal semantic structure. It is suitable for large-scale AI training and high-performance computing systems that require traceability or consistency.

[0051] In one optional implementation, the source computing node generates an IPv6 flow label for each subflow, including the source computing node acquiring identification information from different semantics, the identification information including queue pair identifier, collective communication primitive identifier, algorithm step identifier, message sequence number, and time slice number; performing a bitwise XOR operation on the identification information and a random initial value to obtain the operation result; and obtaining the IPv6 flow label based on the operation result.

[0052] Specifically, stream tags can be generated by performing a bitwise XOR operation on multiple semantic fields. This method constructs high-entropy, unpredictable stream tags by non-linearly combining identifiers from different semantic levels, including but not limited to queue pair identifiers, collective communication sequence numbers, algorithm step identifiers, message sequence numbers, and time slice numbers. For example, the following calculation method can be used:

[0053] The XOR operation effectively disrupts the linear relationship between input fields, making the final generated stream labels no longer exhibit obvious periodic patterns or mathematical structures. Furthermore, the inherent diversity and dynamism of different semantic fields allow for further enhancement of the randomness of stream labels through XOR operations, resulting in a more even distribution of different substreams within the network node hash space.

[0054] Understandably, this method also allows for flexible selection of fields to participate in the mixing based on system requirements. For example: using the collective communication sequence number as the primary factor, with different collective communications having independent flow labels; or using the algorithm steps as the primary factor, with traffic from different steps being scheduled independently; or using queue pair identifiers to participate in the mixing, avoiding label collisions between different queue pairs; or introducing 20-bit random numbers to ensure high randomness and avoid any structural conflicts.

[0055] By using XOR hybrid operation, the problem of alignment between traditional pseudo-random generation methods based on modulo operation and the hash structure of network nodes can be effectively avoided, thus achieving a more stable and controllable multi-path scheduling effect.

[0056] In one optional implementation, the source computing node generates IPv6 flow labels for each sub-flow, including: the source computing node randomly generates an initial flow label for the first sub-flow in the queue pair; and generates IPv6 flow labels for subsequent sub-flows using an incrementing random number method, wherein the flow labels of subsequent sub-flows are incremented by a fixed step size based on the initial flow label.

[0057] Specifically, since most switches have hash functions with good avalanche effect, in an RDMA queue connection, if the flow labels assigned to its sub-flows form a linearly increasing sequence (e.g., with a step size of 1), these increasing flow labels will produce an approximately uniform distribution in the hash space, thereby naturally dispersing the sub-flows to different paths and improving bandwidth utilization.

[0058] Although the Internet Engineering Task Force (IETF) recommends that flow labels be generated using a pseudo-random method, it does not require that flow labels within the same connection must be independent of each other. Therefore, a generation scheme that balances randomness and uniformity can be adopted: an initial flow label is randomly generated for the first sub-flow of the queue pair, and the flow labels for subsequent sub-flows are incremented by a fixed step size based on this initial label. This method satisfies the randomness requirement in RFC 6437 while also ensuring a relatively uniform distribution of sub-flows in the switch's forwarding table.

[0059] In addition to the above methods for generating flow labels, other generation algorithms with perturbation or randomness can also be used. As long as these algorithms can disrupt the distribution structure of flow labels and avoid structural correlation with the hash functions used by network nodes when making path selection, thus preventing the flow label space from aligning with the hash space, a good traffic distribution effect can be achieved.

[0060] During the path selection process, the S103 source compute node and / or network node schedules data packets from different sub-streams to different network paths for transmission based on IPv6 flow labels.

[0061] Once the RDMA application layer sets IPv6 flow labels, compute nodes and network nodes perform traffic scheduling based on IPv6 flow labels.

[0062] In one implementation, during path selection, the source compute node schedules data packets from different sub-flows to different network paths for transmission based on IPv6 flow labels. This includes the source compute node calculating the scheduling weight of each network plane based on the available bandwidth of each network plane fed back by the RDMA flow control protocol; and based on the scheduling weight, combined with the IPv6 flow labels assigned to each sub-flow, distributing data packets from different sub-flows to the corresponding network planes for transmission.

[0063] like Figure 4 As shown, assume that the source compute node is connected to the destination node through several independently constructed network planes. These network planes are physically isolated from each other, have no shared state, and can all reach the same destination address. The source compute node can perform traffic splitting among multiple network planes based on the path selection characteristics of IPv6 flow labels.

[0064] To select the network plane for each subflow, the source node can employ various strategies, such as random selection, round-robin selection, and measurement-based adaptive selection. In the measurement-based strategy, the source node can measure end-to-end performance metrics in real time, such as round-trip time, available bandwidth, link connectivity, and congestion marker count.

[0065] In one embodiment of this application, the source node uses the bandwidth estimate fed back by an RDMA flow control protocol (such as HPCC, DCQCN, or TIMELY) as a weighting basis to perform weighted load balancing on each network plane. Specifically, when a subflow connected to a certain plane obtains higher bandwidth, the source node increases the scheduling weight of that plane; conversely, if a decrease in bandwidth or an increase in round-trip time is measured, the weight of that plane is decreased. The final selection probability of each plane can be expressed as: .

[0066] in, The plane representing the flow control protocol estimation The available bandwidth. Through the above mechanism, the source node can achieve adaptive and performance-driven traffic sharing among multiple planes, enabling multiple subflows to obtain optimal end-to-end performance and improving the overall network resource utilization rate.

[0067] The source computing node identifies the IPv6 flow label of the subflow to which the data packet belongs. According to the current weight distribution of each network plane, it determines the target network plane. The data packet is sent to the destination node through the selected network plane.

[0068] In one embodiment, during the path selection process, the network node schedules data packets of different subflows to different network paths for transmission based on the IPv6 flow label.

[0069] Among them, a network node refers to an intermediate device in a computer network that is responsible for data packet forwarding, routing decision-making, or traffic scheduling. For example, a switch, as a "relay station" for communication, ensures the efficient and reliable transmission of data from the source node to the destination node.

[0070] First, the network node obtains triple information based on the IPv6 flow label, source IP address, and destination IP address of the subflow; performs a hash operation on the triple information to generate a corresponding hash key value.

[0071] In a typical multi-path network, there are multiple available paths between a certain network node and the destination node. This application selects paths for real-time traffic based on the triple <IPv6 flow label, source IP address, destination IP address>. For example, the network node can perform a hash operation on the triple to obtain a key value, and select the corresponding next hop or path according to the key value, thereby achieving distributed scheduling of subflows among multiple paths.

[0072] For the same subflow in this application, its triple remains unchanged and the hash result is always the same. Therefore, all data packets of this subflow will be fixedly assigned by the network node to the same path for transmission, avoiding the multi-path out-of-order problem.

[0073] Furthermore, the network node dynamically determines the scheduling weights of each candidate path based on local link information or end-to-end path information.

[0074] Optionally, the network node determines the scheduling weights of each candidate path based on local link information. The network node first sets a safety threshold for each output queue. Subsequently, the node measures the current buffer occupancy of the queue in real time, and calculates the free space of the queue by subtracting the occupancy from the safety threshold. The node allocates multi-path scheduling weights according to the proportion of the free space of each queue in the total free space.

[0075] Specifically, assuming there are multiple next-hop links between network nodes and their destination, network nodes perform traffic scheduling by measuring the status of these links. In one embodiment, nodes can monitor the performance metrics of these links in real time (such as queue length, buffer occupancy, ECN tag count, etc.) and perform weighted load balancing based on these measurements.

[0076] For each output queue The node first determines the maximum capacity of its available buffer. And introduce a safety factor To prevent the queue from entering a congested state, a safety threshold for the queue is defined as follows:

[0077] Network nodes measure the current buffer occupancy of queues in real time. And based on this, calculate the free space of the queue:

[0078] When the occupancy of a queue exceeds a safety threshold, its available free space becomes 0, and it no longer participates in the next-hop scheduling. Subsequently, the source node or network node allocates multipath scheduling weights based on the free space of each queue:

[0079] This weighting mechanism naturally directs traffic to links with high idle rates, preventing congested links from carrying new sub-flows. Ultimately, this results in fairer occupancy across queues, achieving stable adaptive load balancing and significantly reducing queuing latency and packet loss risk.

[0080] Optionally, network nodes determine the scheduling weight of each candidate path based on end-to-end path information. Network nodes obtain real-time performance metrics (such as one-way latency and congestion information) for each candidate path. Weights are assigned based on the inverse normalized result of path latency, allowing low-latency paths to receive a higher proportion of traffic. This weighting strategy ensures that the product of traffic and latency for each path remains constant, thereby balancing network load and maximizing throughput.

[0081] Specifically, network nodes can obtain cross-node congestion information for multiple candidate paths from source network node s to destination d or to exit network node e (i.e., the network node closest to the destination) through network telemetry mechanisms (such as in-band network telemetry or lightweight bidirectional active measurement protocols). When a data packet carrying an INT header passes through an intermediate network node on the path, each node can write its local measurement metrics, including queuing delay, link utilization, and queue length, into the in-band network telemetry header. After the data packet reaches exit node e or destination d, the in-band network telemetry information can be fed back to source network node s through the return path, enabling the source network node to obtain the overall congestion status of the entire candidate path.

[0082] For lightweight bidirectional active measurement protocols, source network nodes can actively probe packets to measure end-to-end performance metrics such as round-trip time, jitter, packet loss rate, and available bandwidth. Under path symmetry or known time synchronization conditions, the source network node can further estimate the one-way delay from s to e or d, and express it as: .in, Indicates the candidate path number.

[0083] Based on cross-node measurement capabilities, source network nodes can calculate path quality scores for each candidate path. For example, they can weight and combine indicators such as cumulative queuing delay, available bandwidth, and maximum queue length to obtain the quality score for each candidate path.

[0084] In a preferred embodiment, the source network node determines the one-way delay of each candidate path. Calculate the scheduling weight, which is defined as the normalized form of the reciprocal of the delay:

[0085] The aforementioned weights determine the proportion of a path used in scheduling. Therefore, paths with lower latency receive higher weights during scheduling, while paths with higher latency are automatically used less. Since the traffic volume carried by each path in scheduling is directly proportional to its weight, and the weight is inversely proportional to the latency, the product of the traffic carried by a path and its latency can be expressed as: .

[0086] Substituting the weight formula, we get:

[0087] This result is independent of the path number and equal for all paths. This indicates that implementing traffic scheduling in this way will make the total latency of traffic forwarding on each path tend to be equal, thereby balancing the load across different paths and significantly improving the overall network latency performance and effective throughput.

[0088] Finally, based on the hash key and scheduling weight, the data packets of different sub-streams are distributed to the corresponding network paths for transmission.

[0089] Based on a collaborative mechanism of hash keys and scheduling weights, network nodes distribute data packets from different sub-flows to their corresponding network paths. The system performs a hash operation on the triples of each sub-flow to generate a unique hash key to identify the sub-flow. Next, combining the real-time calculated path scheduling weights, a weighted selection algorithm maps the hash keys to specific paths. Data packets are forwarded according to this mapping result, ensuring path consistency within the same sub-flow to maintain sequential semantics, while load balancing is achieved by distributing different sub-flows according to their weights.

[0090] Compute node scheduling occurs before data packets are sent. Its core objective is to determine which network plane a data packet from a given sub-flow should be sent to based on the real-time performance of each network plane. The purpose of triple hashing by network nodes is to randomly but uniformly select one path from multiple local paths. This requires source and destination IP addresses to ensure global uniqueness and flow labels to distinguish sub-flows. Compute node scheduling is strategic and performance-based. It doesn't concern itself with the specific micro-path a data packet takes within a particular switch; it focuses on the macroscopic level—which higher-performing "network plane" the sub-flow should take.

[0091] The traffic scheduling methods for compute nodes and network nodes can operate independently and without interference when both are enabled. Network nodes select paths for data packets based on local congestion signals (such as queue length), achieving local traffic balancing within the network. However, their perspective is limited to the internal network state and they cannot perceive the connection characteristics between compute and network nodes. Compute nodes, on the other hand, proactively adjust the flow label distribution of sub-flows and reallocate traffic paths when they detect global load imbalances through end-to-end measurements, thereby supplementing and correcting the local scheduling of network nodes. This collaborative mechanism achieves load balancing from local to global, significantly improving the overall utilization of network resources. Network nodes ensure micro-path efficiency, while compute nodes correct macro-traffic allocation by adjusting flow label distribution, jointly achieving efficient and stable load balancing.

[0092] This application divides the elephant flow within a single RDMA queue connection into multiple independent sub-flows based on semantic boundaries, assigns a different IPv6 flow label to each sub-flow, and uses the IPv6 flow label as a new path selection identifier. This allows network devices to schedule packets from different sub-flows to different network paths, achieving multi-path traffic scheduling and significantly improving the throughput and network bandwidth utilization of the elephant flow.

[0093] By leveraging the inherent intermittent nature of traffic, semantically independent and temporally separated communication phases are divided into different sub-streams. Because these sub-streams are semantically and temporally independent, even if they arrive in different orders due to transmission via different paths, the end-to-end order semantics required by the RDMA queue for the connection will not be violated, thus fundamentally solving the out-of-order problem that may be caused by multipath transmission.

[0094] The network can schedule at the sub-flow level, achieving finer-grained load balancing than traditional flow-level scheduling. This not only improves the performance of elephant flows but also enables a fairer allocation of network resources among all flows, avoiding local congestion, reducing latency jitter, and thus optimizing overall network performance.

[0095] According to another aspect of the embodiments of this application, a flow tag-based traffic scheduling apparatus for implementing the above-described flow tag-based traffic scheduling method is also provided. For example... Figure 5 As shown, the device includes: The sub-flow partitioning module 501 is used by the source computing node to divide the service flow within a single RDMA queue pair connection into multiple independent sub-flows based on preset semantic boundaries. The sub-flow identification module 502 is used by the source computing node to generate an IPv6 flow label for each sub-flow and fill it into the corresponding field of the IPv6 header when encapsulating data packets; The traffic scheduling module 503 is used by the source computing node and / or network node to schedule data packets of different sub-flows to different network paths for transmission based on IPv6 flow labels during the path selection process.

[0096] It should be noted that the flow tag-based traffic scheduling device provided in the above embodiments is only illustrated by the division of the above functional modules when executing the flow tag-based traffic scheduling method. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the flow tag-based traffic scheduling device and the flow tag-based traffic scheduling method embodiments provided in the above embodiments belong to the same concept, and the implementation process is detailed in the method embodiments, which will not be repeated here.

[0097] According to another aspect of the embodiments of this application, an electronic device corresponding to the flow tag-based traffic scheduling method provided in the foregoing embodiments is also provided to execute the flow tag-based traffic scheduling method described above.

[0098] Please refer to Figure 6 This illustrates a schematic diagram of an electronic device provided by some embodiments of this application. For example... Figure 6As shown, the electronic device includes: a processor 600, a memory 601, a bus 602, and a communication interface 603. The processor 600, the communication interface 603, and the memory 601 are connected via the bus 602. The memory 601 stores a computer program that can run on the processor 600. When the processor 600 runs the computer program, it executes the flow tag-based traffic scheduling method provided in any of the foregoing embodiments of this application.

[0099] The memory 601 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 603 (which can be wired or wireless), such as the Internet, wide area network, local area network, or metropolitan area network.

[0100] Bus 602 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. The memory 601 is used to store programs. After receiving execution instructions, the processor 600 executes the program. The flow tag-based traffic scheduling method disclosed in any of the foregoing embodiments of this application can be applied to the processor 600, or implemented by the processor 600.

[0101] The processor 600 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 600 or by instructions in software form. The processor 600 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules may reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 601. Processor 600 reads the information in memory 601 and, in conjunction with its hardware, completes the steps of the above method.

[0102] The electronic device provided in this application embodiment and the flow tag-based traffic scheduling method provided in this application embodiment are based on the same inventive concept and have the same beneficial effects as the methods they adopt, operate or implement.

[0103] According to another aspect of the embodiments of this application, a computer-readable storage medium corresponding to the flow tag-based traffic scheduling method provided in the foregoing embodiments is also provided, wherein a computer program (i.e., a program product) is stored thereon, and when the computer program is run by a processor, it executes the flow tag-based traffic scheduling method provided in any of the foregoing embodiments.

[0104] It should be noted that examples of computer-readable storage media may also include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other optical and magnetic storage media, which will not be elaborated here.

[0105] The computer-readable storage medium provided in the above embodiments of this application and the flow tag-based traffic scheduling method provided in the embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the applications stored therein.

[0106] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0107] The above embodiments merely illustrate several implementation methods of the present invention, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention. Therefore, the protection scope of this patent should be determined by the appended claims.

Claims

1. A flow label-based traffic scheduling method, characterized in that, include: Based on preset semantic boundaries, the source computing node divides the service flow within a single RDMA queue pair connection into multiple independent sub-flows; The source compute node generates an IPv6 flow label for each sub-flow and fills it into the corresponding field of the IPv6 header when encapsulating the data packet; During the path selection process, the source computing node and / or network node schedules data packets of different sub-streams to different network paths for transmission based on the IPv6 flow labels.

2. The method according to claim 1, characterized in that, Based on preset semantic boundaries, the source compute node divides the service flow within a single RDMA queue connection into multiple independent sub-flows, including: Based on collective communication semantic boundaries, the service flow within a single RDMA queue connection is divided into multiple independent sub-flows; or, Based on the semantic boundaries of the algorithm steps, the service flow within a single RDMA queue pair connection is divided into multiple independent sub-flows; or, Based on the semantic boundaries of data blocks, the service flow within a single RDMA queue connection is divided into multiple independent sub-flows.

3. The method according to claim 1, characterized in that, The source compute node generates IPv6 flow labels for each sub-flow, including: The source computing node, in conjunction with a preset perturbation factor, uses an unpredictable random number generator to generate an approximately uniformly distributed random value; the perturbation factor includes a timestamp, a session identifier, and a queue pair initialization seed; The random value is used as the IPv6 flow label for the sub-flow.

4. The method according to claim 1, characterized in that, The source compute node generates IPv6 flow labels for each sub-flow, including: The source computing node performs cryptographic hashing on preset semantic parameters to obtain the output of the hash function. The semantic parameters include queue pair identifier, collective communication primitive type, and message sequence number. The IPv6 flow label is obtained based on the output of the hash function.

5. The method according to claim 1, characterized in that, The source compute node generates IPv6 flow labels for each sub-flow, including: The source computing node obtains identification information from different semantics, including queue pair identifiers, collective communication primitive identifiers, algorithm step identifiers, message sequence numbers, and time slice numbers; The identification information is XORed with a random initial value to obtain the result. The IPv6 flow label is obtained based on the calculation result.

6. The method according to claim 1, characterized in that, The source compute node generates IPv6 flow labels for each sub-flow, including: The source compute node randomly generates an initial stream label for the first sub-stream within the queue pair; The IPv6 flow labels for subsequent sub-flows are generated using an incremental random number method, and the flow labels for the subsequent sub-flows are incremented by a fixed step size based on the initial flow label.

7. The method according to claim 1, characterized in that, During path selection, the source computing node, based on the IPv6 flow labels, schedules data packets from different sub-flows to different network paths for transmission, including: The source computing node calculates the scheduling weight of each network plane based on the available bandwidth of each network plane fed back by the RDMA flow control protocol. Based on the scheduling weights and combined with the IPv6 flow labels assigned to each sub-flow, the data packets of the different sub-flows are distributed to the corresponding network planes for transmission.

8. The method according to claim 1, characterized in that, During path selection, network nodes, based on the IPv6 flow labels, schedule data packets from different sub-flows to different network paths for transmission, including: Network nodes obtain triplet information based on the IPv6 flow label, source IP address, and destination IP address of the subflow; Perform a hash operation on the triplet information to generate a corresponding hash key value; Network nodes dynamically determine the scheduling weight of each candidate path based on local link information or end-to-end path information; Based on the hash key and the scheduling weight, data packets from different sub-streams are distributed to the corresponding network paths for transmission.

9. A flow tag-based traffic scheduling device, characterized in that, include: The sub-stream partitioning module is used by the source computing node to divide the service flow within a single RDMA queue pair connection into multiple independent sub-streams based on preset semantic boundaries. The sub-flow identification module is used by the source compute node to generate IPv6 flow labels for each sub-flow and fill them into the corresponding fields of the IPv6 header when encapsulating data packets; The traffic scheduling module is used by the source computing node and / or network node to schedule data packets of different sub-flows to different network paths for transmission based on the IPv6 flow labels during the path selection process.

10. An electronic device, characterized in that, It includes a processor and a memory storing program instructions, the processor being configured to execute the flow tag-based traffic scheduling method as described in any one of claims 1 to 8 when executing the program instructions.

Images