A network aggregation method and system for reducing the communication burden of federated learning

Abstract

The present invention discloses an in-network aggregation method and system for reducing the communication burden of federated learning. The method includes using a fish mouth shunting mechanism to split the in-network aggregation into multiple time slots; then using a bottle mechanism to align sparse indexes to achieve effective aggregation; in a dynamic network, using a flying sand mechanism to effectively check packet loss and effectively recover. The solution provided by the present invention can effectively solve the sparse model update, data packet loss and synchronization problems faced by in-network aggregation and federated learning.

Description

Technical Field

[0001] The present invention relates to the field of in-network aggregation technology, and in particular to an in-network aggregation method and system for reducing the communication burden of federated learning. Background Art

[0002] Federated learning (Federated Learning) is a thriving distributed machine learning paradigm that enables clients to participate in collaborative training without sharing raw data. During federated learning training, clients train server-provided models using local raw data and deliver model updates to a central server. Subsequently, the central server aggregates multiple model updates and distributes the results back to the clients. This privacy-preserving approach acts as a bridge across data barriers, facilitating interdisciplinary collaborative innovation in the Internet of Things, healthcare, finance, and other fields. However, a typical federated learning training process involves multiple rounds of interactions between numerous clients and a single server. This frequent data exchange imposes a significant communication burden on the central server, which can cause network congestion and slow down the overall federated learning training process.

[0003] In-network aggregation (INA) is considered a promising approach to alleviate the above communication burden. By leveraging programmable switches (PS) with computing and storage capabilities, model updates uploaded by clients can be aggregated and forwarded at the network layer, thereby reducing traffic to the central server and accelerating federated learning training. Despite its many advantages, deploying INA in distributed scenarios to accelerate federated learning training still faces multiple challenges:

[0004] Challenge 1: In-network aggregation may be delayed due to synchronization issues. Clients participating in federated learning may be heterogeneous in terms of resources, including differences in hardware resources such as CPU, GPU, and different load profiles and data sets. During the INA process, clients with weaker computing power may not be able to complete local training in time. If the PS caches the first arriving data packet, it may cause buffer overflow, while direct forwarding is prone to miss the in-network aggregation and then reach the server directly. Another insight is to perform synchronous aggregation after all clients have completed federated learning training. However, the slowest client may become a bottleneck that limits the efficiency of INA. This observation is called the INA synchronization problem.

[0005] Challenge 2: Model updates originating from clients may be sparse. Federated learning training requires frequent transmission of intermediate data on the “client-PS-server”. As an intermediate node, the PS must handle traffic efficiently. However, such PSs usually have limited memory space and packet processing resources, and aggregating all model updates on the PS may incur a lot of overhead (aggregating 1 billion parameters requires at least 4,000 aggregations). One intuition is that model compression algorithms can interact with INA to jointly speed up communication. In traditional federated learning, sparsification is a popular compression method, and its representative algorithm ToP-k compresses data by selecting the most important K model updates for aggregation. Nevertheless, coarsely aggregating sparse model updates in the network may lead to index mismatches. When each client selects K model updates, if model updates with different indices are not properly aligned, they may be aggregated incorrectly.

[0006] Challenge 3: Mixed packet loss may occur in communication. Data transmission is unreliable in dynamic networks, and occasional packet loss can trigger data loss or aggregation interruption. In addition, packets in intra-network aggregation may be mixed, which means that after aggregation on PS, packets from multiple clients are aggregated into a mixed packet. Therefore, it is difficult for the server to check and recover from packet loss.

[0007] However, current state-of-the-art INA solutions do not adequately address the above challenges. To cope with sparse model updates, some studies have clients vote to reach an index consensus before aggregation. However, discarding model updates outside of consensus may reduce model accuracy. In order to check and recover packet loss in dynamic networks, some studies have suggested that clients use a timeout retransmission mechanism (TRM), but it is difficult to handle aggregated mixed packets. In addition, the synchronization problem caused by client heterogeneity has been widely studied in traditional federated learning. Unfortunately, most existing efforts do not take into account the memory-limited PS, making it difficult to migrate them directly to in-network federated learning aggregation. Therefore, deploying in-network aggregation to accelerate federated learning training provides an important research opportunity that deserves further exploration. Summary of the invention

[0008] In order to solve the technical problems that deployment of in-network aggregation to federated learning has challenges in synchronization, sparse model update, and aggregate mixed packet loss, etc., the embodiments of the present invention provide an in-network aggregation method and system for reducing the communication burden of federated learning.

[0009] The technical solution of the embodiment of the present invention is achieved as follows:

[0010] An embodiment of the present invention provides an in-network aggregation method for reducing the communication burden of federated learning, which is applied to an in-network aggregation system for reducing the communication burden of federated learning. The system includes multiple clients, multiple programmable switches and servers. The method includes:

[0011] Initialization phase: The client submits a registration request to the server to participate in federated learning; after successful registration, the server sends the setting parameters to the client, which include model parameters, training parameters, and verification ID; after the client completes model training, in the first round, the programmable switch directly forwards the model update uploaded by the client to the server without aggregation; the server receives model updates from all clients and records the upload time of each client;

[0012] Routing strategy configuration phase: Based on the statistical upload time, the fish mouth mechanism establishes a routing strategy to aggregate data flows at the same time level; the server synchronously aggregates all model updates to obtain a global model, and transmits the updated model parameters and routing strategy to the client and programmable switch respectively;

[0013] Index alignment phase: The client continues to train the updated model, and the programmable switch updates the routing table. After training, the client compresses the model update and uploads the sparse data index to the programmable switch. The Aquarius mechanism aligns multiple sparse indexes, filters out overlapping indexes, and then sends the filtered results back to the client. Based on the returned results, the client packages and sorts the model updates and adds an identification bit to each data packet.

[0014] Detection phase: When the server receives all data packets in a time slot round, the Feisha mechanism confirms whether there is any data packet loss through XOR check ID; if packet loss occurs, the server receives the data packet retransmitted by the client; if not, the server sends a character confirmation signal to the client, asynchronously aggregates the model update in the data packet, generates a new global model, and repeats the above steps after the first round.

[0015] In one embodiment, the fish mouth mechanism comprises:

[0016] Given a set of heterogeneous clients , , represents the i-th client, which is used to train on a local dataset to obtain a model update and upload the model update to the server;

[0017] Given a set of multi-stage programmable switches , , represents a j-th programmable switch, the programmable switch being used to aggregate and forward the model update;

[0018] Set up a time list , the time list is calculated from the client upload time in the first round; the values ​​in the time list are sorted in ascending order; and starting from the first value after sorting, whether the data streams of two clients are at the same time level is determined by the following calculation formula:

[0019] ;

[0020] in, Indicates the upload time of the i-th client; Indicates the upload time of the i+1th client; is a hyperparameter, and the calculation formula is:

[0021] ;

[0022] in, It is a time list The difference between the maximum and minimum values ​​in is a hyperparameter, is the number of programmable switches;

[0023] Step-by-step search on multi-level programmable switches and The intersection of and Respectively represent the clients in the network Reachable set of programmable switches and clients The set of programmable switches that can be reached, ;

[0024] exist In the case where there is only one programmable switch, if the programmable switch load meets the maximum load required for aggregation of all clients, the aggregation of all client model updates is completed directly on the programmable switch; if the programmable switch load cannot meet the maximum load required for aggregation of all clients, the aggregation scheme with the minimum time variance is selected, and the aggregation scheme with the minimum time variance is:

[0025] ;

[0026] in, Indicates the average upload time of the client; Indicates the number of clients; Indicates the programmable switch load; Indicates the maximum load required by all clients aggregated;

[0027] exist When there are multiple programmable switches, select the programmable switch with the least number of connected clients, and find the programmable switch with the smallest load among the programmable switches with the least number of connected clients as the aggregator; if the load of the programmable switch can meet the maximum load required for aggregation of all clients, then the aggregation of all client model updates is completed directly on the programmable switch; if the load of the programmable switch cannot meet the maximum load required for aggregation of all clients, then the aggregation scheme with the smallest time variance is selected.

[0028] In one embodiment, the Aquarius mechanism includes:

[0029] The client compresses the model update through the sparsification strategy and uploads the index of the compressed data to the programmable switch;

[0030] The programmable switch determines the index of the client that needs to be aggregated on the programmable switch, calculates the overlapping index and distributes it back to the client;

[0031] The client receives the returned index and sorts and packages the model update; wherein, the overlapping data will be encapsulated in a separate data packet corresponding to the non-overlapping index and sent in an index value sequence; an identification bit is attached to the data packet, the identification bit of the overlapping index is 1, and the identification bit other than the overlapping index is 0; for the data packet with the identification bit being 1, the programmable switch parses the data packet and updates the aggregation result of the same index, and for the data packet with the identification bit being 0, the programmable switch is downgraded to an ordinary switch and only forwards the data packet to the server.

[0032] In one embodiment, the flying sand mechanism includes:

[0033] In the first round of communication after registration, federated learning assigns an ID to each client on the server side; when the data packets are aggregated on the programmable switch, the IDs are summed according to the XOR rule; the XOR rule is ;

[0034] The server checks the aggregation identifier bits and the theoretical value K to determine whether a packet in the aggregate packet is lost by the following calculation formula;

[0035] ;

[0036] Where L is the value of the identifier bit in the aggregated data packet, K is the theoretical value, and the calculation formula is: ;

[0037] In the case of determining that a packet is lost, the location of the lost packet is determined by any of the following two schemes, and retransmitted packets are received for recovery;

[0038] The first method: Under unstable network conditions, each programmable switch maintains a client table and records the aggregated data streams from the clients; the aggregation model in the programmable switch is updated to the maximum within the time WT; WT is the slowest time for the data stream to reach the programmable switch; if the data stream of any client arrives later than the time WT, a retransmission is prompted; the programmable switch merges the existing data packets and uploads the results to the next node; the next node checks the packet loss according to the routing table and repeats the above operations;

[0039] The second method: Under stable network conditions, split the intra-network aggregation into multiple time slots and use the XOR identifier bit to confirm the packet loss location according to the following calculation formula;

[0040] ;

[0041] in, The client ID of the packet loss;

[0042] The identification bit of the retransmitted data packet is set to 0, and the server makes a secondary judgment on the identifier bit of the retransmitted data packet and L. When the retransmission data packets are received, the retransmission data packets are aggregated; otherwise, the retransmission data packets are discarded.

[0043] The embodiment of the present invention further provides an in-network aggregation system for reducing the communication burden of federated learning, the system comprising multiple clients, multiple programmable switches and servers; the system performs the following steps:

[0044] Initialization phase: The client submits a registration request to the server to participate in federated learning; after successful registration, the server sends the setting parameters to the client, which include model parameters, training parameters, and verification ID; after the client completes model training, in the first round, the programmable switch directly forwards the model update uploaded by the client to the server without aggregation; the server receives model updates from all clients and records the upload time of each client;

[0045] Routing strategy configuration phase: Based on the statistical upload time, the fish mouth mechanism establishes a routing strategy to aggregate data flows at the same time level; the server synchronously aggregates all model updates to obtain a global model, and transmits the updated model parameters and routing strategy to the client and programmable switch respectively;

[0046] Index alignment phase: The client continues to train the updated model, and the programmable switch updates the routing table. After training, the client compresses the model update and uploads the sparse data index to the programmable switch. The Aquarius mechanism aligns multiple sparse indexes, filters out overlapping indexes, and then sends the filtered results back to the client. Based on the returned results, the client packages and sorts the model updates and adds an identification bit to each data packet.

[0047] Detection phase: When the server receives all data packets in a time slot round, the Feisha mechanism confirms whether there is any data packet loss through XOR check ID; if packet loss occurs, the server receives the data packet retransmitted by the client; if not, the server sends a character confirmation signal to the client, asynchronously aggregates the model update in the data packet, generates a new global model, and repeats the above steps after the first round.

[0048] In one embodiment, the fish mouth mechanism comprises:

[0049] Given a set of heterogeneous clients , , represents the i-th client, which is used to train on a local dataset to obtain a model update and upload the model update to the server;

[0050] Given a set of multi-stage programmable switches , , represents a j-th programmable switch, the programmable switch being used to aggregate and forward the model update;

[0051] Set up a time list , the time list is calculated from the client upload time in the first round; the values ​​in the time list are sorted in ascending order; and starting from the first value after sorting, whether the data streams of two clients are at the same time level is determined by the following calculation formula:

[0052] ;

[0053] in, Indicates the upload time of the i-th client; Indicates the upload time of the i+1th client; is a hyperparameter, and the calculation formula is:

[0054] ;

[0055] in, It is a time list The difference between the maximum and minimum values ​​in is a hyperparameter, is the number of programmable switches;

[0056] Step-by-step search on multi-level programmable switches and The intersection of and Respectively represent the clients in the network Reachable set of programmable switches and clients The set of programmable switches that can be reached, ;

[0057] exist In the case where there is only one programmable switch, if the programmable switch load meets the maximum load required for aggregation of all clients, the aggregation of all client model updates is completed directly on the programmable switch; if the programmable switch load cannot meet the maximum load required for aggregation of all clients, the aggregation scheme with the minimum time variance is selected, and the aggregation scheme with the minimum time variance is:

[0058] ;

[0059] in, Indicates the average upload time of the client; Indicates the number of clients; Indicates the programmable switch load; Indicates the maximum load required by all clients aggregated;

[0060] exist When there are multiple programmable switches, select the programmable switch with the least number of connected clients, and find the programmable switch with the smallest load among the programmable switches with the least number of connected clients as the aggregator; if the load of the programmable switch can meet the maximum load required for aggregation of all clients, then the aggregation of all client model updates is completed directly on the programmable switch; if the load of the programmable switch cannot meet the maximum load required for aggregation of all clients, then the aggregation scheme with the smallest time variance is selected.

[0061] In one embodiment, the Aquarius mechanism includes:

[0062] The client compresses the model update through the sparsification strategy and uploads the index of the compressed data to the programmable switch;

[0063] The programmable switch determines the index of the client that needs to be aggregated on the programmable switch, calculates the overlapping index and distributes it back to the client;

[0064] The client receives the returned index and sorts and packages the model update; wherein, the overlapping data will be encapsulated in a separate data packet corresponding to the non-overlapping index and sent in an index value sequence; an identification bit is attached to the data packet, the identification bit of the overlapping index is 1, and the identification bit other than the overlapping index is 0; for the data packet with the identification bit being 1, the programmable switch parses the data packet and updates the aggregation result of the same index, and for the data packet with the identification bit being 0, the programmable switch is downgraded to an ordinary switch and only forwards the data packet to the server.

[0065] In one embodiment, the flying sand mechanism includes:

[0066] In the first round of communication after registration, federated learning assigns an ID to each client on the server side; when the data packets are aggregated on the programmable switch, the IDs are summed according to the XOR rule; the XOR rule is ;

[0067] The server checks the aggregation identifier bits and the theoretical value K to determine whether a packet in the aggregate packet is lost by the following calculation formula;

[0068] ;

[0069] Where L is the value of the identifier bit in the aggregated data packet, K is the theoretical value, and the calculation formula is: ;

[0070] In the case of determining that a packet is lost, the location of the lost packet is determined by any of the following two schemes, and retransmitted packets are received for recovery;

[0071] The first method: Under unstable network conditions, each programmable switch maintains a client table and records the aggregated data streams from the clients; the aggregation model in the programmable switch is updated to the maximum within the time WT; WT is the slowest time for the data stream to reach the programmable switch; if the data stream of any client arrives later than the time WT, a retransmission is prompted; the programmable switch merges the existing data packets and uploads the results to the next node; the next node checks the packet loss according to the routing table and repeats the above operations;

[0072] The second method: Under stable network conditions, split the intra-network aggregation into multiple time slots and use the XOR identifier bit to confirm the packet loss location according to the following calculation formula;

[0073] ;

[0074] in, The client ID of the packet loss;

[0075] The identification bit of the retransmitted data packet is set to 0, and the server makes a secondary judgment on the identifier bit of the retransmitted data packet and L. When the retransmission data packets are received, the retransmission data packets are aggregated; otherwise, the retransmission data packets are discarded.

[0076] This embodiment has the following beneficial effects:

[0077] This embodiment adds three mechanisms to address the challenges of deploying INA to federated learning training. To alleviate synchronization issues, the fish mouth mechanism generates routing policies for clients with the same time level. For sparse model updates, the Aquarius mechanism filters out the parts that overlap with the INA index, and the rest can only be forwarded to the server. In addition, if packet loss occurs in a dynamic network, Feisha is used for packet loss detection and retransmission aggregation. The solution of this embodiment can effectively solve the sparse model update, data packet loss and synchronization problems faced by in-network aggregation and federated learning. BRIEF DESCRIPTION OF THE DRAWINGS

[0078] Figure 1 A schematic diagram of a flow chart of an intra-network aggregation method for reducing the communication burden of federated learning according to an embodiment of the present invention;

[0079] Figure 2 This is a schematic diagram of the Dujiangyan workflow of an embodiment of the present invention;

[0080] Figure 3 A schematic diagram showing a comparison between the fish mouth mechanism of an embodiment of the present invention and a traditional in-network aggregation solution;

[0081] Figure 4 A schematic diagram of the motivation and workflow of the Aquarius mechanism according to an embodiment of the present invention;

[0082] Figure 5 A schematic diagram of the packet loss difficulty and flying sand mechanism of detecting mixed data packets according to an embodiment of the present invention;

[0083] Figure 6 This is a schematic diagram of the test platform environment of an embodiment of the present invention;

[0084] Figure 7 Schematic diagram of algorithm accuracy and convergence performance of the embodiment of the present invention; wherein, Figure 7 (a) Schematic diagram of the algorithm accuracy and convergence performance of the ResNet-18 model; Figure 7 (b) Schematic diagram of the algorithm accuracy and convergence performance of the VGG-16 model; Figure 7 (c) Schematic diagram of the algorithm accuracy and convergence performance of the LeNet-5 model; Figure 7 (d) Schematic diagram of the algorithm accuracy and convergence performance of the AlexNe model;

[0085] Figure 8A schematic diagram of communication traffic overhead on a server according to an embodiment of the present invention;

[0086] Fig. 9 Schematic diagram of the effectiveness experimental results of the packet loss mechanism of an embodiment of the present invention;

[0087] Fig.10 1 is a diagram showing the internal structure of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0088] Before introducing the solution of this embodiment, we first introduce the related work of in-network aggregation and federated learning in dealing with sparse model updates, packet loss and synchronization problems.

[0089] 1Intra-network aggregation (INA)

[0090] With the advent of programmable switches, intermediate data can be aggregated in the switch, reducing the amount of traffic that initially flows to the server. SwitchML explores in-network training of deep neural networks (DNNs) to accelerate their communication. At its core, a single switch centrally aggregates parameter updates from service workers, partially replacing the functionality of a central server. In addition, SwitchML introduces timeout retransmission and memory replication mechanisms for packet loss. ATP is the following work of SwitchML, which designs a multi-job distributed DNN training setting. ATP supports best-effort aggregation. To detect and handle packet loss, ATP uses timeout-based retransmissions or out-of-order parameter acknowledgment character packets from the PS. SOAR studies the problem of activating a limited number of in-network computing devices within the network, aiming to reduce the overall network utilization for a given workload.

[0091] To further speed up communication, model compression algorithms (e.g., sparsification) are introduced to interact with INA. Libra is an in-network aggregation framework for distributed sparse deep learning training. Based on observations of sparse deep learning applications, Libra aggregates gradients on PS only for hot parameters and leaves other cold parameter updates in a central server. However, the identification of hot parameters relies on the entire dataset without the constraints of data privacy in federated learning. To align sparse indexes, FediAC proposes a two-stage scheme for voting-based consensus model compression that supports index alignment for multiple compression algorithms. Nonetheless, FediAC aims to centrally aggregate parameter updates from multiple clients for PS, while not focusing on general multi-level PS scenarios with a central server.

[0092] 2. Synchronization Issues in Federated Learning

[0093] In federated learning, clients train models using their local data and upload model updates to a central server. These model updates can be aggregated into a global model guided by different aggregation strategies. Affected by client heterogeneity, such as different computing power and non-independent and identically distributed (Non-IID) data, model updates from multiple clients arrive at the server asynchronously. In synchronous federated learning (S-federated learning), all clients need to upload a local model before the global model is aggregated. Therefore, the slowest client may become a bottleneck limiting the aggregation efficiency, which is known as the synchronization problem or the stragglers problem. To exploit the idle waiting time, adaptive synchronization schemes dynamically configure federated learning training settings, including batch size, learning rate, and more rounds of local training to derive a high-quality global model. In addition, to make the synchronization problem easier to avoid, many asynchronous aggregation schemes have been proposed, in which servers aggregate models without waiting for all local updates. Although these improvements can effectively alleviate the synchronization problem, they are designed for federated learning coordinated by a central server and do not consider PS with limited memory.

[0094] Based on the above related work in the field, inspired by the ancient irrigation system, this embodiment proposes a general in-network aggregation framework (Dujiangyan), which accelerates federated learning training through flow control. At its core, Dujiangyan uses the fish mouth diversion mechanism to split the in-network aggregation into multiple time slots, and then uses the treasure bottle mechanism to align the sparse index to achieve effective aggregation. In a dynamic network, Dujiangyan can also effectively check for packet loss and recover effectively. This embodiment also verifies the convergence of Dujiangyan through theoretical analysis. In addition, the experimental numerical results show that Dujiangyan is significantly better than other baselines, and can achieve a 5.41-fold acceleration ratio in terms of training convergence, and the aggregation efficiency is improved by 23.07%.

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

[0096] The embodiment of the present invention provides an in-network aggregation method for reducing the communication burden of federated learning, which is applied to an in-network aggregation system for reducing the communication burden of federated learning. The system includes multiple clients, multiple programmable switches and servers, such as Figure 1 As shown, the method includes:

[0097] Step 101: Initialization phase: The client submits a registration request to the server to participate in federated learning; after successful registration, the server sends setting parameters to the client, the setting parameters include model parameters, training parameters and verification ID; after the client completes model training, in the first round, the programmable switch directly forwards the model update uploaded by the client to the server without aggregation; the server receives model updates from all clients and records the upload time of each client;

[0098] Step 102: Routing strategy configuration phase: Based on the statistical upload time, the fish mouth mechanism establishes a routing strategy to aggregate data flows at the same time level; the server synchronously aggregates all model updates to obtain a global model, and transmits the updated model parameters and routing strategy to the client and the programmable switch respectively;

[0099] Step 103: Index alignment phase: The client continues to train the updated model, and the programmable switch updates the routing table. After training, the client compresses the model update and uploads the sparse data index to the programmable switch. The Aquarius mechanism aligns multiple sparse indexes, filters out overlapping indexes, and then sends the filtered results back to the client. Based on the returned results, the client packages and sorts the model updates and adds an identification bit to each data packet.

[0100] Step 104: Detection phase: When the server receives all data packets in a time slot round, the Feisha mechanism confirms whether there is any data packet loss through XOR check ID; if packet loss occurs, the server receives the data packet retransmitted by the client; if not, the server sends a character confirmation signal to the client, asynchronously aggregates the model update in the data packet, generates a new global model, and repeats the above steps after the first round.

[0101] This embodiment proposes a general in-network aggregation framework (Dujiangyan) to accelerate federated learning training through flow control. Specifically, to alleviate the synchronization problems caused by heterogeneous clients, this embodiment designs Fish Mouth, a diversion mechanism, to establish an in-network aggregation routing strategy in multiple time slots. In order to avoid aggregation errors and inefficiencies that may occur under various sparsification methods, this embodiment proposes a Aquarius mechanism to filter overlapping indexes. In dynamic networks, this embodiment designs a flying sand mechanism to solve the obstacles faced by servers in mixed packet loss detection and recovery. The convergence of Dujiangyan is proved from theoretical analysis.

[0102] In essence, aggregating data from multiple clients in a multi-stage PS network is a traffic engineering problem. Given the similarities between data flow and water flow processing problems, learning from excellent water conservancy projects may be a potential solution. The Dujiangyan irrigation system is characterized by damless water diversion, which takes advantage of favorable conditions based on terrain characteristics to pursue the goal of water diversion. Inspired by this, this embodiment proposes a general in-network aggregation framework, also called Dujiangyan, to aggregate sparse model updates from heterogeneous clients, ultimately accelerating federated learning training. The workflow of Dujiangyan is as follows Figure 2 As shown, it can be divided into the following steps:

[0103] Initialization phase: The client submits a registration request to the server to participate in federated learning. After successful registration, the server sends the setup parameters (model parameters, training parameters, and verification ID) to the client. After the client completes model training, in the first round, the PS directly forwards the model updates uploaded by the client instead of aggregating them. The server receives model updates from all clients and then records the upload time of each client.

[0104] Routing strategy configuration phase: Based on the statistical upload time, the fish mouth mechanism establishes a routing strategy, hoping to aggregate data flows at the same time level. The server synchronously aggregates all model updates to obtain a global model, and passes the updated model parameters and routing strategy to the client and PS respectively.

[0105] Index alignment phase: The client continues to train the updated model, and the PS updates the routing table. After training, the client compresses the model update and uploads the sparse data index to the PS. The Aquarius mechanism aligns multiple sparse indexes, filters out overlapping indexes, and then sends them back to the client. Based on the returned results, the client packages and sorts the model updates. In order to make it easy for the PS to distinguish packets with overlapping indexes, the client adds an identification bit to each packet.

[0106] Detection phase: When the server receives all data packets in a time slot round, Feisha confirms whether there is any data packet loss through XOR check ID. If packet loss occurs, the server receives the data packet retransmitted by the client; if not, the server sends a character confirmation signal to the client, asynchronously aggregates the model update in the data packet, generates a new global model, and repeats the above steps after the first round.

[0107] Compared with traditional INA, Dujiangyan adds three mechanisms to address the challenges of deploying INA to federated learning training. To alleviate the synchronization problem, the fish mouth mechanism generates routing strategies for clients with the same time level. For sparse model updates, the Aquarius mechanism filters out the parts that overlap with the INA index, and the rest can only be forwarded to the server. In addition, if packet loss occurs in a dynamic network, Dujiangyan uses Feisha for packet loss detection and retransmission aggregation. It is also worth noting that Dujiangyan's central server uses a synchronous aggregation strategy in the first round, and then an asynchronous aggregation strategy (aggregating client model updates with clients at the same time level).

[0108] Challenge 1: Intra-network aggregation may be delayed due to synchronization issues

[0109] In order to cope with the above challenges, this embodiment proposes a fish mouth, which is a diversion mechanism of Dujiangyan, and is expected to aggregate adjacent time-level data streams.

[0110] A PS that aggregates data streams from all connected clients may experience synchronization issues. Figure 3 The upper subfigure in illustrates such a specific example, where the PS receives data streams from clients with different training times. Figure 3 It can be observed that the clients C1 and C3, which train more slowly, become the bottleneck of aggregation. Although the local training is completed quickly, C2 and C4 have to wait for time t1 and t2 respectively. In order to turn these faster training clients into advantages, this embodiment proposes a fish mouth mechanism, which essentially builds a routing strategy for multiple time-level data streams. Figure 3 The lower subgraph in shows the design concept of the fish mouth. Here PS3 acts as an aggregator for slower time-level model updates. It can be another PS where clients C1 and C3 are reachable within the network, and may receive data streams forwarded or aggregated by the connected PSs (i.e., C3→PS2→PS3). Compared with the upper subgraph, the data from client C1 is aggregated with the data from client C3 instead of C2. Under this scheme, some PSs can release the resources occupied by aggregation and only forward data streams. At the same time, the values ​​of t1 and t2 can be significantly reduced. Therefore, the method for determining the time level of multiple clients is crucial. This embodiment assumes that federated learning training is performed in a distributed network. Given a set of heterogeneous clients represents the i-th client. The client trains on the local dataset to obtain model updates, uploads them to the central server, and then Indicates aggregation and forwarding on the jth programmable switch. In the fish mouth, this embodiment maintains a time list , which is calculated from the client upload time in the first round. This embodiment sorts the values ​​in U in ascending order to eliminate traversal in subsequent calculations. Yuzui tends to prioritize solutions for clients that complete local training faster. Starting from the first value of Search the client stream at the same time level:

[0111] ;

[0112] in yes The difference between the maximum and minimum values ​​in . Afterwards, whether the data streams of two clients are at the same time level can be determined by the following equation:

[0113] ;

[0114] if and In accordance with Equation 2, they can be considered to be of the same time level. The value of is critical, because if it is too large, the waiting time for aggregation may be very long, and if it is too small, it may not be possible to find the same time level client subset. Therefore, this embodiment experimentally discusses different choices in Sec. VB In order to establish a routing table for a multi-slot INA, this embodiment gradually searches for multiple levels of PS. and The intersection of and ( ) represent the clients in the network and client PS that can be achieved. The subsets of may be diverse, and this example discusses them in two cases:

[0115] There is only one PS in the intersection: if the PS load satisfies If the aggregation of all clients is sufficient, the diversion routing strategy is directly finalized; otherwise, it means that the PS load does not support the aggregation of all client data flows. Under the PS load constraint, this embodiment selects the aggregation solution with the smallest variance:

[0116] ;

[0117] There are multiple PSs in the intersection: for example, data flows from clients C1 and C2 can be aggregated in PS1, PS2, and PS3. This embodiment proposes a minimum edge minimum load (MEML) algorithm to select an aggregator. In MEML, this embodiment first tends to select the PS with the smallest edge (the least number of connected clients), and then finds the PS with the smallest load among them as the aggregator. If a set of PSs can aggregate all data flows under the load constraint, the diversion routing strategy can be finally determined; otherwise, it means that the load in the PS is heavy or some data flows cannot reach one PS. In this case, this embodiment selects the solution with the smallest variance under the above constraints.

[0118] It is worth noting that the above two solutions are both bottom-up approaches. When the lower-level PS set cannot aggregate all the data streams of the same time level, this embodiment will use the value of the parsed data Set to (The maximum number of data streams that the client can aggregate in PS ), and then send the unparsed part to the upper layer to find the aggregation node. The server executes the asynchronous global aggregation strategy after receiving all the aggregation packets of similar time level, and then sends the updated model to the contributing clients.

[0119] Challenge 2: Model updates from the client may be sparse

[0120] To address the above challenges, this embodiment proposes a drainage mechanism of Dujiangyan - Baoping. Although INA can significantly reduce the communication traffic on the link to the server, aggregating and forwarding all model updates on PS may incur large communication overhead. Sparsification is an effective model compression method with a compression ratio of up to p times (p is the number of model updates). However, directly aggregating model updates with mismatched indexes may cause aggregation errors. To make it easier to understand, this embodiment uses a simple example to reveal the cause of such errors. After local training, the model updates are sparse, and the data indexes in client C1 are [1,2,3,4,5], and C3 are [4,5,6,7,8]. Simply aggregating this data in sequence may produce aggregation errors due to inconsistent data indexes. In addition, as the client adopts multiple sparsification strategies, aggregating variable-length data will encounter more troubles. For example, ToP-2 means that C1 obtains [2,3], and ToP-3 means that C3 obtains [3,4,5].

[0121] One key is to align the indexes first, then do the aggregation, like Figure 4As shown in the sub-figure on the left. Driven by this strategy, C1 and C3 send data with the same index sequentially after index alignment, and finally, PS aggregates data from 8 indexes. However, the communication compression rate of these 8 aggregations is only 80% instead of the expected 50%. This can be attributed to the fact that aggregating model parameters using indexes [1,2,3] and [6,7,8] is not beneficial for communication optimization because these data are aggregated with value 0. In contrast, the amount of data of index [4,5] is compressed from 4 to 2, so it is effective to aggregate them on PS. Inspired by this, this embodiment proposes an overlapping stream filtering mechanism, called Aquarius, which can be divided into three steps, corresponding to Figure 4 The three sub-graphs on the right:

[0122] (1) The client compresses the model update through the sparsification strategy and then uploads the index of the corresponding data to the PS.

[0123] (2) According to the routing policy made by Fish Mouth in the first round, PS receives from all clients that the indexes must be aggregated here. After that, PS calculates the overlapping indexes and distributes them back to the clients.

[0124] (3) The client receives the returned index and sorts and packages the model update. Overlapping data will be encapsulated in separate data packets corresponding to non-overlapping indexes and sent in a sequence of index values. To facilitate distinction, this embodiment adds an identification bit to each data packet, with the overlapping index being 1 and the others being 0. For data packets with an identification bit of 1, the PS parses the data packet and updates the aggregation result of the same index. For data packets with an identification bit of 0, the PS is downgraded to a normal switch and only forwards the data packet to the server.

[0125] In addition, this embodiment adds an identification bit in the packet header to distinguish overlapping data. In Baoping, the model update is then sparsely distributed, filtering out the unprofitable parts of aggregation, thereby improving the aggregation efficiency and avoiding aggregation errors. Figure 4 In some cases, the polymerization efficiency can be increased from 25% to 100%.

[0126] Challenge 3: Aggregate mixed packet loss may occur in communication

[0127] In order to solve the difficulty of detecting and recovering the loss of aggregated mixed data packets, this embodiment designs flying sand. Flying sand is a flood discharge and sand removal mechanism in the Dujiangyan irrigation system to ensure that floods do not affect the downstream. In this embodiment, flying sand is a packet loss calibration and recovery mechanism that checks for packet loss and avoids repeated aggregation of retransmitted data packets. In a dynamic network, packet loss may exacerbate aggregation errors or data loss. For example, in Figure 4In the example, packet loss from client C1 to PS may interrupt aggregation. Therefore, packet loss calibration and recovery are essential for efficient INA, so this embodiment proposes a flying sand mechanism.

[0128] For the data flow forwarded by PS, Feisha uses the timeout retransmission mechanism (TRM) to check packet loss. Specifically, when the packet sent by the client exceeds the retransmission timeout (RTO) and the packet is still not acknowledged, this packet will be retransmitted until it is sent.

[0129] For PS forwarded data flows, Feisha uses a timeout retransmission mechanism (TRM) to check for packet loss. Specifically, when a packet sent by a client exceeds the retransmission timeout (RTO) and the packet is still not acknowledged, the packet will be retransmitted until it is sent successfully. However, for PS aggregated data flows, the rough use of TRM encounters difficulties. Figure 5 illustrates the difficulty in loss detection for aggregated mixed packets. If packet loss occurs from C6 to PS5, after aggregation by PS3, PS5, and PS6, the packets from multiple clients are aggregated into a single mixed packet, and it is difficult for the server to acknowledge the packet loss.

[0130] To this end, this embodiment proposes to add an identifier bit ( Figure 5 Specifically, in the first round of communication after registration, federated learning assigns an ID to each client on the server side. When data packets are aggregated on the PS, these IDs are combined according to the XOR rule (i.e. ) is summed. The ID-XOR-sum method is naturally applicable to INA, because the server can directly determine the packet loss in the aggregated packet by checking the aggregate identifier bits. By default, this embodiment maintains a theoretical value K on the server, which can be calculated as follows: ;

[0131] Assume that the value of the identifier bit in the aggregate packet is L. Indicates packet loss. Therefore, the server must confirm the location of the packet loss and then receive the retransmitted data packet for recovery. However, since the packet loss time is unknown, relying solely on the XOR identifier bit to find the exact location of the packet loss faces multiple obstacles. Reserving bytes in the packet header to indicate where the packet loss occurred makes the packet header more complicated, thereby preventing each packet from containing more model updates. In order to cope with different network conditions, this embodiment provides two packet loss recovery solutions:

[0132] FS-Bad: In the case of poor network conditions, each PS maintains a client table and records the aggregated data flows from the clients. Instead of waiting for all data flows to arrive, the PS aggregation model is updated in a best-effort manner within time WT, where WT is the slowest time for a data flow to arrive at the PS, which can be obtained from the fish mouth. Given that the upload times of the data flows routed to the PS are similar, if the data flow of any client arrives later than time WT, the system will prompt a retransmission. Afterwards, the PS merges the existing data packets and uploads the results to the next node. Similarly, the next node checks the packet loss according to the routing table and performs the same operations as above. It is worth noting that if a PS experiences packet loss, all data packets aggregated by this PS must be retransmitted.

[0133] FS-Stable: Under stable network conditions, in the interactive mode of Fish Mouth and Aquarius, the network aggregation is split into multiple time slots. Since the aggregate data is more sparse, this embodiment recommends using the XOR identifier bit to directly confirm the packet loss location: .

[0134] In addition, when the PS must aggregate data from other clients in the next time slot, the aggregated retransmitted data may affect the XOR identifier bit, resulting in a false positive of packet loss. Therefore, this embodiment sets the identifier bit of the retransmitted data packet to 0, and this part of the data is only forwarded on the PS instead of aggregated, avoiding conflicts with the data stream of the next time slot. In addition, the retransmitted data packet may cause repeated aggregation errors, which means that the model updates from the client will be aggregated multiple times. Therefore, in the two schemes implemented above, the identifier bit of the retransmitted data packet will be judged twice together with L, and only when Otherwise, they will be discarded in this round of aggregation.

[0135] In order to analyze the feasibility of the proposed federated learning training framework, this embodiment performs a convergence analysis on the proposed Dujiangyan. There is a standard routine for convergence analysis of federated learning, so this embodiment follows it and adopts the following general assumptions that are widely used in previous work.

[0136] Assumption 1. Smoothness) Assume that the loss function f on all clients is L-smooth for any model parameters x and y, , ;

[0137] Assumption 2. (Bounded Gradients) The squared norm of the stochastic gradient and the variance of the stochastic gradient in each client are uniformly bounded.

[0138] ;

[0139] in Represents a sample randomly selected from the client's local data.

[0140] Assumption 3. (Existence of Optimization) Assume that the loss function of the trained model has a minimum .

[0141] Since the information of model update is lost during the sparsification process, this embodiment defines the compression error as:

[0142] ;

[0143] in , , and is a constant, so that , is the average error, is the average model update.

[0144] Theorem 1. Assume that the client uses an unbiased sampling scheme and local training Round. represents the local learning rate, Represents the global learning rate. According to the above assumptions, after T rounds, we have: ;

[0145] in , The degree to which the data are non-independent and identically distributed (non-IID) , .

[0146] Remark 1. Theorem 1 can be proved based on theoretical derivation using biased compression operation. It is shown that for nonconvex, L-smooth and For non-IID data, the convergence performance of Dujiangyan is affected by the local training time and q value of the heterogeneous client. Without loss of generality, the value of q is different for each global training round of Dujiangyan. For example, in the first round and 1≤q≤n. Based on the above intuition, Dujiangyan detects as many clients as possible at the same time level in each time slot, develops an excellent routing strategy, reduces the communication time of each round, and thus accelerates the convergence speed of federated learning aggregation in the network.

[0147] Performance Evaluation

[0148] 1 Experimental Setup

[0149] Test platform: Figure 6As shown, this embodiment evaluates the performance of Dujiangyan in extensive test bench experiments, which are carried out on 2 ITX-3588J (OS: 64-bit Ubuntu 23.10, CPU: 8 cores 64-bit, NPU) as low-performance PS, 1 workstation (CPU: 13th Generation Intel(R) Core(TM) i9-13900H 2.60GHz, RAM: 32 GB, GPU: NVIDIA GeForce RTX 4060) as high-performance PS and server, 3 Raspberry Pi5 (OS: 64-bit Ubuntu 23.10, CPU: 4 Cortex-A76, GPU: 800 MHz VideoCore 7), 1 NVIDIA Jetson Nano (OS: 64-bit Ubuntu 23.10, CPU: 4 CortexA57, GPU: 128 core NVIDIA Maxwell) and 1 NVIDIA Jetson TX-2 (OS: 64-bit Ubuntu 23.10, CPU: 2 Cortex-A57 and 2 Denver2 64-bit CPUs, GPU: 256 NVIDIACUDA cores), 4 Raspberry Pi4 (operating system: 64-bit Ubuntu 23.10, CPU: 4 CortexA72, GPU: 600 MHz VideoCore 6) as clients. In this embodiment, three virtual hosts are created on each 2ITX-3588J and workstation (two as high-performance PS and one as a server), and the switch topology is 1 core-3 aggregation-4 leaves. The above devices build a local area network through a WIFI hotspot. In this embodiment, the socket library of python is used to establish communication, and the model training of each client is implemented through the Pytorch framework. The implementation of data processing and file operations is based on the distributed Hadoop and Spark systems.

[0150] Model and Dataset: This embodiment experiments on two datasets, including MNIST and CIFAR-10. CIFAR10 contains 60,000 32 × 32 color images, labeled into 10 classes, of which 50,000 samples are used for training and 10,000 samples are used for testing. MNIST has the same number of classes as CIFAR10, but contains 70,000 28 × 28 grayscale handwritten photos, of which 60,000 samples are used for training and 10,000 samples are used for testing. This embodiment uses 4 Classic models to train the dataset. For the CIFAR-10 dataset, this embodiment uses VGG-16, ResNet-18, and LeNet-5. For the MNIST dataset, this embodiment uses AlexNet.

[0151] Federated learning setting: For all datasets in the Non-IID setting, this example evenly divides the dataset into N subsets for customers to use, and then each customer randomly adds Subset. In this embodiment, the number of local training rounds for each client is set to 1, the batch size of the data set is 128, the learning rate is 0.01, the decay step is 10, and the decay is stopped after 50 rounds. Since the current commercial programmable switches do not support floating-point calculations, the floating-point numbers are first converted to integers, and then the ToP k algorithm is used to perform sparse updates on the model.

[0152] Comparison algorithms:

[0153] Conv-ex, which is an extension of the traditional INA (i.e. SwitchML). Conv-ex waits for all clients to complete local training before aggregating to PS.

[0154] Select, which selects n clients for federated learning training in each round. Here, this embodiment expands it according to the result of Yuzui to select clients with the same INA time level.

[0155] SOAR, which builds aggregation trees with only a few aggregation switches to obtain lower network bandwidth utilization, instead of using as many aggregation switches as possible in the tree.

[0156] Libra: It only aggregates the gradients of hot parameters (a certain number of frequently updated parameters) in programmable switches and leaves other cold parameter updates in the central server. It uses a subset of the training set to train the model and selects frequently updated parameters in advance. Since the servers in federated learning cannot obtain the original data, this embodiment sets the hot parameters to half of the larger value parameters that reach the server in the first round.

[0157] FediAC: This is a federated learning in-network aggregation algorithm with compression. To guarantee consensus compression across clients (i.e., ensure that the aggregation index is consistent across all clients), clients report their important model update indexes to the PS to estimate the global important model updates.

[0158] GAIN: It aggregates model updates at programmable ingress switches in a stateless manner. GAIN maintains a sliding window per source node, which includes packets that have been sent but not acknowledged and packets that can be sent in the future. For safe loss recovery, it uses timeout as an indicator to identify whether a packet is lost, and then re-aggregates the retransmitted packets at the switch instead of just forwarding them.

[0159] 2 Experimental results

[0160] Training accuracy and convergence: This example compares the training accuracy and convergence of Dujiangyan and three baselines, including VGG16, LeNet5, ResNet18, and AlexNet. To ensure fairness, all methods share the same federated learning settings (i.e., batch size, Non-IID degree, number of local training times, and learning rate). In addition, this example also considers sparse models for comparison, where the client compresses model updates through the Top-50% algorithm (retaining 50% of the parameters). This example evaluates the model on the test set after each round of global aggregation to collect training accuracy and determine convergence through model loss. The experimental results are shown in Figure 2. Figure 7 shown.

[0161] Compared with the baseline, Dujiangyan shows the best convergence speed among the four models, followed by Select. SOAR and Conv-ex need to wait for the backward client, so the convergence time is longer. Dujiangyan uses the fish mouth mechanism to split the aggregation into multiple time slots, thereby achieving faster aggregation while ensuring training accuracy. Compared with Select, SOAR, and Conv-ex, Dujiangyan can increase the federated learning training speed from 3.6× to 5.41× on ResNet18, from 3.38× to 5.2× on VGG16, from 3.01× to 5.41× on VGG16, and from 1.90× to 2.147× on AlexNet. Dujiangyan's advantage is not prominent on AlexNet because AlexNet is trained on a simpler dataset and thus only takes a few rounds to reach convergence.

[0162] Select performs the best in the first round of aggregation time, while Dujiangyan performs the worst. However, as the number of communication rounds increases, Dujiangyan's multiple slot aggregation compensates for the time spent on formulating the strategy. Unlike SOAR and Conv-ex, which use a synchronous aggregation strategy, and Select, which uses asynchronous, Dujiangyan adopts a synchronous strategy in the first round and uses asynchronous thereafter. Although some old parameters under the asynchronous strategy have a negative impact on model convergence, Dujiangyan can achieve the same high training accuracy as the comparison method in the four models. This is mainly due to its ability to complete more rounds of aggregation in a shorter time.

[0163] Traffic on the central server: In order to demonstrate another superior performance of Dujiangyan in communication compression, this example further evaluates the traffic overhead of the central server. Figure 8 It shows the traffic overhead of the central server as the model converges. From the experimental results, it can be observed that Dujiangyan is good at reducing communication traffic, which is similar to Select. Especially on LeNet5, due to the small parameters on LeNet5, the communication advantage of intra-network aggregation is hidden and difficult to observe, while it is more obvious in models with more parameters such as VGG16.

[0164] Compared to Conv-ex, Dujiangyan can reduce traffic by 64.99%, 33.93%, 61.64%, and 63.06% across four models, respectively. Compared to SOAR, Dujiangyan can also reduce traffic by 55.51%, 18.41%, 26.22%, and 34.65%, respectively. Interestingly, these results are consistent with Figure 7 The results are contrary to the intuitive perception depicted. Dujiangyan can significantly reduce the traffic overhead when training more rounds on a small model like LeNet5. However, the effect of reducing communication overhead may not be so obvious when training simple tasks on larger models. It is also worth noting that the waiting methods (i.e., Conv-ex and SOAR) have more traffic overhead than Dujiangyan and Select. As with Conv-ex, the aggregated traffic in higher-level PSs may not be encountered. In SOAR, the traffic can only be aggregated in a few PSs.

[0165] Aggregation efficiency and compression ratio: This example uses the VGG16 training task to evaluate the performance of Dujiangyan and its competitors in terms of aggregation efficiency and compression ratio. To ensure robustness, all numerical results are weighted to demonstrate the average performance of the aggregatable switches on the testbed of this example. The experimental results are shown in Table 1, where Top-50% retains 50% of the largest parameters, Top-75% retains 75% of the largest parameters, and Top-mix represents a hybrid of the first two. AE represents aggregation efficiency, and CR is compression ratio.

[0166] Table 1 Polymerization efficiency and compression ratio performance

[0167]

[0168] Among all the compared methods, Dujiangyan shows the best aggregation efficiency of these compression algorithms, followed by FediAC. The improvement of efficient aggregation for memory-constrained switches is not significant on Libra, and the compression rate of aggregated data cannot be significantly reduced because it only aggregates hot parameters with fixed indexes. Compared with Libra, Dujiangyan can improve the aggregation efficiency by 23.07%, 10.81%, and 20.84% ​​in the three compression strategies, respectively, while still improving the compression rate by 6.04%, 8.01%, and 6.28%, respectively. Compared with FediAC, Dujiangyan can improve the aggregation efficiency while ensuring the data compression rate under three different compression algorithms. It is also worth mentioning that as the parameters become sparser, the less INA works, and the advantage of Dujiangyan becomes weaker. Since there are fewer overlapping indexes, the less INA works. Therefore, this embodiment recommends not to update the model too sparsely.

[0169] Packet loss recovery: To achieve packet loss recovery, Dujiangyan uses the Feisha packet loss handling mechanism with two schemes for dynamic networks. This embodiment uses the ResNet18 training task as an example on the test bed. To evaluate packet loss, this embodiment selectively drops packets on the switch to simulate different network environments, with packet loss rates ranging from 0.01% to 0.1%. Fig. 9 The performance for different packet loss rates is demonstrated, where the performance loss is measured by the increase in training time. When the packet loss rate is 0.01%, both FlyingSand and Gain show excellent packet loss resilience. However, as the packet loss rate increases, the performance on FS-Stable loses.

[0170] When the packet loss rate is higher than 1%, the performance is significantly improved, even close to 3%. FS-Bad shows the actual performance of packet loss recovery, followed by Gain. From the experimental results, it can be observed that the flying sand mechanism has achieved significant improvements in this embodiment, and the performance loss is less than 1% even when the packet loss rate is 1%.

[0171] Selection of parameter α: The convergence speed of federated learning is positively correlated with the number of participating clients q in each round. Considering that the value of q in Dujiangyan training is mainly affected by the parameter α in the fish mouth mechanism. This embodiment further evaluates the impact of Dujiangyan parameter α in four models. No fixed α can reliably achieve optimal performance. Specifically, α=0.5 is the best solution on LeNet5 and AlexNet, α=2 is the best solution on ResNet18, and α=1 is the best solution for VGG16. α is a key parameter that can substantially affect the convergence speed. In practice, this embodiment also found that the choice of value α is also affected by the client training time gap and the complexity of the training task (model and data set). This embodiment recommends using a larger α when the training time gap between clients is small, and when the task is more complex and the training time for a round is longer, it is recommended to use a smaller α.

[0172] This embodiment proposes a general in-network aggregation framework for federated learning, called Dujiangyan. With traffic control as the core, Dujiangyan is mainly composed of the fish mouth diversion mechanism and the bottle diversion mechanism, which work perfectly together to solve the synchronization problems and low aggregation efficiency that arise from heterogeneous clients and sparse model updates. In addition, this embodiment designs a packet loss detection mechanism and two recovery schemes for aggregated mixed data packets to adapt to different network conditions. Theoretical analysis and experiments have demonstrated the effectiveness and efficiency of Dujiangyan, which can achieve a 5.41× acceleration ratio in training convergence and an aggregation efficiency improvement of 23.07%.

[0173] The main contributions of this embodiment can be summarized as follows:

[0174] (1) This embodiment proposes an in-network aggregation scheme for federated learning training, called Dujiangyan, which can effectively improve communication performance and aggregation efficiency.

[0175] (2) In order to solve the challenges of synchronization, sparse model update and packet loss, this embodiment proposes effective mechanisms including fish mouth, treasure bottle and flying sand.

[0176] (3) This example evaluates the performance of the algorithm in a testbed environment. Extensive experiments on real datasets and classical models demonstrate the efficacy and efficiency of Dujiangyan.

[0177] In order to implement the method of the embodiment of the present invention, the embodiment of the present invention also provides an in-network aggregation system for reducing the communication burden of federated learning, the system includes multiple clients, multiple programmable switches and servers; the system executes the steps of the above-mentioned method.

[0178] The above-mentioned system provided in this embodiment belongs to the same concept as the above-mentioned method embodiment. The specific implementation process thereof is detailed in the method embodiment and will not be repeated here.

[0179] In order to implement the method of the embodiment of the present invention, the embodiment of the present invention also provides a computer program product, which includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the steps of the above method.

[0180] Based on the hardware implementation of the above program modules, and in order to implement the method of the embodiment of the present invention, the embodiment of the present invention further provides an electronic device (computer device). Specifically, in one embodiment, the computer device may be a terminal, and its internal structure diagram may be as follows: Fig.10 As shown. The computer device includes a processor A01, a network interface A02, a display screen A04, an input device A05 and a memory (not shown in the figure) connected through a system bus. Among them, the processor A01 of the computer device is used to provide computing and control capabilities. The memory of the computer device includes an internal memory A03 and a non-volatile storage medium A06. The non-volatile storage medium A06 stores an operating system B01 and a computer program B02. The internal memory A03 provides an environment for the operation of the operating system B01 and the computer program B02 in the non-volatile storage medium A06. The network interface A02 of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor A01, the method of any one of the above embodiments is implemented. The display screen A04 of the computer device can be a liquid crystal display screen or an electronic ink display screen, and the input device A05 of the computer device can be a touch layer covered on the display screen, or a key, trackball or touchpad set on the computer device housing, or an external keyboard, touchpad or mouse, etc.

[0181] Those skilled in the art will understand that Fig.10 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0182] The device provided by the embodiment of the present invention includes a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, the method of any one of the above embodiments is implemented.

[0183] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

[0184] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of the processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0185] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0186] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable device. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0187] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0188] The memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0189] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media 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 memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0190] It can be understood that the memory of the embodiment of the present invention can be a volatile memory or a non-volatile memory, and can also include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM); the magnetic surface memory can be a disk memory or a tape memory. The volatile memory can be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM), synchronous static random access memory (SSRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM, SyncLink Dynamic Random Access Memory), and direct RAMbus random access memory (DRRAM, Direct Rambus Random Access Memory).The memories described in the embodiments of the present invention are intended to include, but are not limited to, these and any other suitable types of memories.

[0191] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0192] The above are only embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included within the scope of the claims of the present application.

Claims

1. An intra-network aggregation method for reducing the communication burden of federated learning, characterized in that: An in-network aggregation system for reducing the communication burden of federated learning, the system comprising a plurality of clients, a plurality of programmable switches and a server, and the method comprising: Initialization phase: The client submits a registration request to the server to participate in federated learning; after successful registration, the server sends the setting parameters to the client, which include model parameters, training parameters, and verification ID; after the client completes model training, in the first round, the programmable switch directly forwards the model update uploaded by the client to the server without aggregation; the server receives model updates from all clients and records the upload time of each client; Routing strategy configuration phase: Based on the statistical upload time, the fish mouth mechanism establishes a routing strategy to aggregate data flows at the same time level; the server synchronously aggregates all model updates to obtain a global model, and transmits the updated model parameters and routing strategy to the client and programmable switch respectively; Index alignment phase: The client continues to train the updated model, and the programmable switch updates the routing table. After training, the client compresses the updated model and uploads the sparse data index to the programmable switch. The Aquarius mechanism aligns multiple sparse indexes, filters out overlapping indexes, and then sends the filtered results back to the client. Based on the returned results, the client packages and sorts the model updates and adds an identification bit to each data packet. Detection phase: When the server receives all data packets in a time slot round, the Feisha mechanism confirms whether there is any data packet loss by performing an XOR operation on the verification ID; if packet loss occurs, the server receives the data packet retransmitted by the client; if not, the server sends a character confirmation signal to the client, asynchronously aggregates the model update in the data packet, generates a new global model, and repeats the above steps after the first round.

2. The method for reducing the communication burden of federated learning according to claim 1, characterized in that: Fish mouth mechanism, including: Given a set of heterogeneous clients , , represents the i-th client, which is used to train on the local dataset to obtain model updates and upload the model updates to the server; N is the number of clients; Given a set of multi-stage programmable switches , , represents a j-th programmable switch, the programmable switch being used to aggregate and forward the model update; Set up a time list , the time list is calculated from the client upload time in the first round; the values ​​in the time list are sorted in ascending order; and starting from the first value after sorting, whether the data streams of two clients are at the same time level is determined by the following calculation formula: ； in, Indicates the upload time of the i-th client; Indicates the upload time of the i+1th client; is a hyperparameter, and the calculation formula is: ； in, It is a time list The difference between the maximum and minimum values ​​in is a hyperparameter, is the number of programmable switches; Step-by-step search on multi-level programmable switches and The intersection of and Respectively represent the clients in the network Reachable set of programmable switches and clients The set of programmable switches that can be reached, ; exist In the case where there is only one programmable switch, if the programmable switch load meets the maximum load required for aggregation of all clients, the aggregation of all client model updates is completed directly on the programmable switch; if the programmable switch load cannot meet the maximum load required for aggregation of all clients, the aggregation scheme with the minimum time variance is selected, and the aggregation scheme with the minimum time variance is: ； in, Indicates the average upload time of the client; Indicates the number of clients; Indicates the programmable switch load; Indicates the maximum load required by all clients aggregated; exist When there are multiple programmable switches, select the programmable switch with the least number of connected clients, and find the programmable switch with the smallest load among the programmable switches with the least number of connected clients as the aggregator; if the load of the programmable switch can meet the maximum load required for aggregation of all clients, then the aggregation of all client model updates is completed directly on the programmable switch; if the load of the programmable switch cannot meet the maximum load required for aggregation of all clients, then the aggregation scheme with the smallest time variance is selected.

3. The method for reducing the communication burden of federated learning according to claim 1, characterized in that: Aquarius Mechanism, including: The client compresses the model update through the sparsification strategy and uploads the index of the compressed data to the programmable switch; The programmable switch determines the index of the client that needs to be aggregated on the programmable switch, calculates the overlapping index and distributes it back to the client; The client receives the returned index and sorts and packages the model update; wherein, the overlapping data will be encapsulated in a separate data packet corresponding to the non-overlapping index and sent in an index value sequence; an identification bit is attached to the data packet, the identification bit of the overlapping index is 1, and the identification bit other than the overlapping index is 0; for the data packet with the identification bit being 1, the programmable switch parses the data packet and updates the aggregation result of the same index, and for the data packet with the identification bit being 0, the programmable switch is downgraded to an ordinary switch and only forwards the data packet to the server.

4. The method for reducing the communication burden of federated learning according to claim 3, characterized in that: Flying sand mechanism, including: In the first round of communication after registration, federated learning assigns an ID to each client on the server side; when the data packets are aggregated on the programmable switch, the IDs are summed according to the XOR rule; the XOR rule is: ； The server checks the aggregation identifier bits and the theoretical value K to determine whether a packet in the aggregate packet is lost by the following calculation formula; ； Where L is the value of the identifier bit in the aggregated data packet, K is the theoretical value, and the calculation formula is: ; represents the verification ID of the i-th client, and N is the number of clients; In the case of determining that a packet is lost, the location of the lost packet is determined by any of the following two schemes, and retransmitted packets are received for recovery; The first method: Under unstable network conditions, each programmable switch maintains a client table and records the aggregated data streams from the clients; the aggregation model in the programmable switch is updated to the maximum within the time WT; WT is the slowest time for the data stream to reach the programmable switch; if the data stream of any client arrives later than the time WT, a retransmission is prompted; the programmable switch merges the existing data packets and uploads the results to the next node; the next node checks the packet loss according to the routing table and repeats the above operations; The second method: Under stable network conditions, split the intra-network aggregation into multiple time slots and use the XOR identifier bit to confirm the packet loss location according to the following calculation formula; ； in, The client ID of the packet loss; The identification bit of the retransmitted data packet is set to 0, and the server makes a secondary judgment on the identifier bit of the retransmitted data packet and L. When the retransmission data packets are received, the retransmission data packets are aggregated; otherwise, the retransmission data packets are discarded.

5. An intra-network aggregation system for reducing the communication burden of federated learning, characterized in that: The system includes multiple clients, multiple programmable switches and servers; the system performs the following steps: Initialization phase: The client submits a registration request to the server to participate in federated learning. After successful registration, the server sends the setting parameters to the client, including model parameters, training parameters, and verification ID. After the client completes model training, in the first round, the programmable switch directly forwards the model updates uploaded by the client to the server without aggregation; the server receives the model updates from all clients and records the upload time of each client; Routing strategy configuration phase: Based on the statistical upload time, the fish mouth mechanism establishes a routing strategy to aggregate data flows at the same time level; the server synchronously aggregates all model updates to obtain a global model, and transmits the updated model parameters and routing strategy to the client and programmable switch respectively; Index alignment phase: The client continues to train the updated model, and the programmable switch updates the routing table. After training, the client compresses the updated model and uploads the sparse data index to the programmable switch. The Aquarius mechanism aligns multiple sparse indexes, filters out overlapping indexes, and then sends the filtered results back to the client. Based on the returned results, the client packages and sorts the model updates. And add a flag bit to each data packet; Detection phase: When the server receives all data packets in a time slot round, the Feisha mechanism confirms whether there is any data packet loss by performing an XOR operation on the verification ID; If packet loss occurs, the server receives the data packet retransmitted by the client; if not, the server sends a character confirmation signal to the client, asynchronously aggregates the model updates in the data packet, generates a new global model, and repeats the above steps after the first round.

6. The in-network aggregation system for reducing the communication burden of federated learning according to claim 5, characterized in that: Fish mouth mechanism, including: Given a set of heterogeneous clients , 1 , represents the i-th client, which is used to train on the local dataset to obtain model updates and upload the model updates to the server; N is the number of clients; Given a set of multi-stage programmable switches , , represents a j-th programmable switch, the programmable switch being used to aggregate and forward the model update; Set up a time list , the time list is calculated from the client upload time in the first round; the values ​​in the time list are sorted in ascending order; and starting from the first value after sorting, whether the data streams of two clients are at the same time level is determined by the following calculation formula: ； in, Indicates the upload time of the i-th client; Indicates the upload time of the i+1th client; is a hyperparameter, and the calculation formula is: ； in, It is a time list The difference between the maximum and minimum values ​​in is a hyperparameter, is the number of programmable switches; Step-by-step search on multi-level programmable switches and The intersection of and Respectively represent the clients in the network Reachable set of programmable switches and clients The set of programmable switches that can be reached, ; exist In the case where there is only one programmable switch, if the programmable switch load meets the maximum load required for aggregation of all clients, the aggregation of all client model updates is completed directly on the programmable switch; if the programmable switch load cannot meet the maximum load required for aggregation of all clients, the aggregation scheme with the minimum time variance is selected, and the aggregation scheme with the minimum time variance is: ； in, Indicates the average upload time of the client; Indicates the number of clients; Indicates the programmable switch load; Indicates the maximum load required by all clients aggregated; exist When there are multiple programmable switches, select the programmable switch with the least number of connected clients, and find the programmable switch with the smallest load among the programmable switches with the least number of connected clients as the aggregator; if the load of the programmable switch can meet the maximum load required for aggregation of all clients, then the aggregation of all client model updates is completed directly on the programmable switch; if the load of the programmable switch cannot meet the maximum load required for aggregation of all clients, then the aggregation scheme with the smallest time variance is selected.

7. The in-network aggregation system for reducing the communication burden of federated learning according to claim 5, characterized in that: Aquarius Mechanism, including: The client compresses the model update through the sparsification strategy and uploads the index of the compressed data to the programmable switch; The programmable switch determines the index of the client that needs to be aggregated on the programmable switch, calculates the overlapping index and distributes it back to the client; The client receives the returned index and sorts and packages the model update; wherein, the overlapping data will be encapsulated in a separate data packet corresponding to the non-overlapping index and sent in an index value sequence; an identification bit is attached to the data packet, the identification bit of the overlapping index is 1, and the identification bit other than the overlapping index is 0; for the data packet with the identification bit being 1, the programmable switch parses the data packet and updates the aggregation result of the same index, and for the data packet with the identification bit being 0, the programmable switch is downgraded to an ordinary switch and only forwards the data packet to the server.

8. The in-network aggregation system for reducing the communication burden of federated learning according to claim 7, characterized in that: Flying sand mechanism, including: In the first round of communication after registration, federated learning assigns an ID to each client on the server side; when the data packets are aggregated on the programmable switch, the IDs are summed according to the XOR rule; the XOR rule is: ； The server checks the aggregation identifier bits and the theoretical value K to determine whether a packet in the aggregate packet is lost by the following calculation formula; ； Where L is the value of the identifier bit in the aggregated data packet, K is the theoretical value, and the calculation formula is: ; represents the verification ID of the i-th client, and N is the number of clients; In the case of determining that a packet is lost, the location of the lost packet is determined by any of the following two schemes, and retransmitted packets are received for recovery; The first method: Under unstable network conditions, each programmable switch maintains a client table and records the aggregated data streams from the clients; the aggregation model in the programmable switch is updated to the maximum within the time WT; WT is the slowest time for the data stream to reach the programmable switch; if the data stream of any client arrives later than the time WT, a retransmission is prompted; the programmable switch merges the existing data packets and uploads the results to the next node; the next node checks the packet loss according to the routing table and repeats the above operations; The second method: Under stable network conditions, split the intra-network aggregation into multiple time slots and use the XOR identifier bit to confirm the packet loss location according to the following calculation formula; ； in, The client ID of the packet loss; The identification bit of the retransmitted data packet is set to 0, and the server makes a secondary judgment on the identifier bit of the retransmitted data packet and L. When the retransmission data packets are received, the retransmission data packets are aggregated; otherwise, the retransmission data packets are discarded.

Images