Pith. sign in

REVIEW 4 major objections 6 minor 76 references

Flotilla: A scalable, modular and resilient federated learning framework for heterogeneous resources

T0 review · 4 major / 6 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read The paper claims that a state-centered, event-driven design can make an FL framework simultaneously modular, resilient, and scalable, with server failover in under a second and 1.7% overhead at 1080 clients.

desk verdict Flotilla is a genuine systems contribution with real experiments, but the headline server-failover claim is only demonstrated for the simplest strategy and the 92.5% weak-scaling number is missing from the body. read the letter →

arxiv 2507.02295 v1 pith:J7HZYIXI submitted 2025-07-03 cs.DC

Roopkatha Banerjee , Prince Modi , Jinal Vyas , Chunduru Sri Abhijit , Tejus Chandrashekar , Harsha Varun Marisetty , Manik Gupta , Yogesh Simmhan This is my paper
classification cs.DC
keywords federatedlearningasynchronousaggregationserverfailoverclientfaulttoleranceedgedevicesscalabilitymodularFLframeworkRedisstatestore
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper is trying to establish that a federated learning framework can be built around modular, event-driven client-selection and aggregation modules plus an externalized session state, and that this design is enough to make the framework competitive across the axes FL systems actually need: rapid composition of synchronous and asynchronous strategies, tolerance of client dropouts and server death, small resource footprint on low-end edge devices, and scaling beyond a thousand clients. If that claim holds, Flotilla gives systems researchers and practitioners a single platform on which novel FL strategies can be implemented in tens to hundreds of lines, deployed unchanged from simulation to real Raspberry Pi and Jetson clusters, and compared against each other on equal terms. The paper supports the claim by implementing five FL strategies, injecting failures on 200+ clients and between two servers, and benchmarking resource usage against three established FL frameworks.

What carries the argument

The load-bearing mechanism is the state-centric training lifecycle with pluggable strategy modules. The central objects are the five persistent session states and the two module interfaces, `clientSelect(...)` and `aggregate(...)`, each of which receives read-only access to other modules' states and read-write access to its own. The event-driven loop is what allows synchronous and asynchronous behavior to coexist: the client-selection module is invoked on every client response and can either return new clients or defer, while the aggregation module can stash local models or return a new global model. Failure recovery is declared to work by reconstructing these states from Redis or disk and resuming the same event loop.

What would settle it

Set up a FedAT or TiFL session with Redis-backed states, kill the leader after the client-selection state records the chosen clients for a tier but before the aggregation state has a matching entry, then let a standby leader resume; if the resumed run's round count, tier bookkeeping, or accuracy trajectory differs from an uninterrupted run in a way that mirrors the partial write, the failover claim fails for strategies that do not add their own consistency checks.

Watch

Extended reading notes

Core claim

On the paper's own terms, the discovery is that federated learning orchestration can be reduced to an event-driven lifecycle over a small set of named session states, and that this reduction is what buys modularity, resilience, and scale simultaneously. Flotilla's leader maintains five state objects — Client Info, Training Session, Client Selection, Client Training, and Aggregation — and exposes each one to client-selection (CS) and aggregation (Agg) modules with either read-only or read-write wrappers. Every client response triggers the lifecycle in the same order (selection, training, aggregation, validation), so a synchronous strategy like FedAvg can defer aggregation until all selected models arrive while FedAsync aggregates immediately on receipt; the same interfaces implement TiFL, HACCS, and FedAT. Clients are stateless: they receive model code on demand, send heartbeats over MQTT, and return trained models over gRPC, so a client failure just removes one participant from the pool. The leader's session state can be mirrored to Redis or checkpointed to disk, letting a standby server restore and resume a session in under a second with only the interrupted round lost. The paper's evaluations then report that this design yields 59–246 lines of code per implemented strategy, near-identical accuracy when 89 of 208 clients fail, 1.7% framework overhead at 1080 clients versus Flower's 54.9%, and resource usage on Raspberry Pi and Jetson clusters comparable to or better than Flower, OpenFL, and FedML.

Load-bearing premise

When a server dies mid-round, the saved session state may be only partially written; Flotilla's fast failover works only if each FL strategy's modules can tell which parts of that state are still consistent and safely resume from it.

Editorial extensions

If this is right

  • A researcher can move a strategy from single-machine simulation to a real edge cluster by changing a YAML file, since the same leader and client deployment executes both modes.
  • Client failures no longer require restarting a session: heartbeat detection plus a per-round timeout lets training continue with the remaining pool, and the paper reports near-identical final accuracy when 89 of 208 clients were killed.
  • Server failover becomes a deployable option: with Redis mirroring, another server can resume the session in under a second, losing at most the partial round, plus only a few seconds of checkpointing cost every five rounds.
  • Large-scale containerized FL emulation is practical: Flotilla's overhead stays at 1.7% of wall time with 1080 clients and 100 training calls per round, where the paper measures Flower's overhead at 54.9%.
  • An apples-to-apples comparison on real hardware can change conclusions drawn from simulation; the paper's five-strategy runs find FedAvg and FedAsync often match or beat the sophisticated strategies on final accuracy within a fixed time budget.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A testable extension is to use the Redis-backed state as a hook for checkpointing at finer granularity than one round; the paper's own overhead numbers (about 143 ms per disk checkpoint for LeNet and 24.8 MiB of cumulative state for CCNN) suggest that mid-round resumption could be made nearly continuous.
  • The partial-state caveat implies a design pressure on future FL strategies: authors who want reliable failover should specify which of their state keys must be written atomically, and the paper explicitly leaves stronger built-in consistency for future work.
  • The observation that sophisticated strategies did not beat FedAvg and FedAsync on real hardware, despite tuning to the settings in their papers, points to a community-level need to report systems-level convergence results rather than only simulated accuracy; the paper itself draws this conclusion for the five strategies it implemented.
  • Flotilla's state model could be reused for other orchestration tasks, such as multiple concurrent sessions or hierarchical FL, which the paper names as future work but does not implement.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. This paper presents Flotilla, a federated learning (FL) framework designed for modular composition of client-selection and aggregation strategies, stateless clients, and server-side session state that can be checkpointed to disk or externalized to Redis. The authors implement five FL strategies (FedAvg, TiFL, HACCS, FedAsync, FedAT) and evaluate them on a Raspberry Pi cluster, a Jetson cluster, and containerized clusters with up to 1080 clients. The paper further claims client-failure tolerance and server-failure failover, reports weak-scaling performance versus Flower, and compares resource usage (CPU, memory, round time) with Flower, OpenFL, and FedML on the Pi cluster. The central claim is that Flotilla provides a scalable, modular, and resilient platform for FL systems research and deployment on heterogeneous edge hardware.

Significance. The paper's main strengths are its breadth of empirical evaluation: real hardware (three Pi types, four Jetson types), 1080 containerized clients, five strategies spanning synchronous/asynchronous aggregation, fault-injection experiments for client and server failures, and a direct comparison with three established FL frameworks. The finding that simple baselines match or beat sophisticated strategies on real hardware is a useful reproducibility-oriented result, and the stated open-source release would benefit the community. If the resilience and scalability claims are supported by the intended fixes, Flotilla would be a competitive platform. However, several headline claims—general server failover for stateful strategies, the 92.5% weak-scaling efficiency, and resource comparison on Jetsons—are not backed by the current evidence.

major comments (4)
  1. [Sec. 3.5 and Sec. 4.4.1] The general server-failover claim is not supported for the stateful asynchronous strategies that the paper highlights. Sec. 3.5 concedes that the externally persisted state may be a partial state and that modules need to estimate the consistency of the keys they wish to use, with stronger consistency models deferred to future work. The only server-failure experiment (Sec. 4.4.1) uses CCNN/CIFAR10-IID/FedAvg, whose Aggregation State is a simple stash of local models for the current round and is reconcilable by waiting for the remaining clients. The FedAT pseudocode in Appendix A.1, by contrast, maintains tierAggNum counters in both the Client Selection State and the Aggregation State, and a tier model is written before the CS counter is advanced; a crash in that window can double-count an update or deadlock the recovered session. Since no fault-injection experiment covers FedAsync or FedAT, the paper's claim that the external state store makes Flotilla generally resilient to server failures (Sec. 5) is an extrapolation rather than a demonstrated result. In addition, Contribution 2's wording that training is resumed within 820ms of detection is misleading: the 820ms is only leader startup plus state restoration, while actual resumption of training takes an additional ~171s to complete the partial round. The claim should be qualified to state the partial-round completion time explicitly.
  2. [Sec. 1.4 Contribution 3 and Sec. 4.5] The paper claims a weak-scaling efficiency of 92.5% in Contribution 3, citing Sec. 4.5, but Sec. 4.5 never defines or reports a weak-scaling efficiency metric. The section reports end-to-end training times and overhead percentages for 56, 112, 160, 208, and 1080 clients, but no efficiency number appears. Either the metric must be defined and computed from the reported data, or the claim should be removed.
  3. [Abstract and Sec. 4.6.2] The abstract states that Flotilla's resource usage on Raspberry Pis and Nvidia Jetson edge accelerators is comparable to or better than three state-of-the-art FL frameworks, but the only cross-framework resource comparison is performed on the Raspberry Pi cluster (Fig. 13). No CPU, memory, or round-time comparison on the Jetson cluster is presented. The claim should be restricted to the Pi cluster or supported by additional experiments.
  4. [Sec. 4.4.3] The client-failure tolerance experiment uses only CCNN/CIFAR10-IID/FedAvg, and the paper itself attributes the negligible accuracy impact to the IID data distribution. The resilience claims in the abstract and conclusions are not conditioned on IID data, so the current experiment is insufficient to establish client-failure tolerance for non-IID workloads, where the loss of clients with particular label distributions can bias the global model. The evaluation should either include a non-IID fault-injection run or the claims should be qualified.
minor comments (6)
  1. [Sec. 4.1.3, Table 5] The table header reads 'Jenson-Shannon Score' but should be 'Jensen-Shannon Score'.
  2. [Sec. 4.4.1, Fig. 10a] The legend labels and the text descriptions are inconsistent: the text describes 'Single Machine Fail' while the figure shows 'Single Machine Fails' and 'Server Resuming.' Please align the terminology and clarify which lines correspond to each setup.
  3. [Sec. 2.2.1] The sentence 'This avoiding users having to write any code if existing modules suffice' should read 'This avoids users having to write any code if existing modules suffice.'
  4. [Sec. 3.5] The phrase 'A discrete checkpointing strategy' should likely be 'A disk checkpointing strategy,' and the distinction between disk checkpointing and the Redis external state store should be made explicit.
  5. [Sec. 4.6.2] The text describes OpenFL memory usage in MiB while Fig. 13 plots memory in GB; please harmonize the units for consistency.
  6. [Sec. 4.1.2] The sentence 'Client missing 5 consecutive heartbeats are marked inactive' should be 'Clients missing five consecutive heartbeats are marked inactive.'

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: Flotilla's central claims rest on external benchmarks and direct measurements; the resilience caveat is a support gap, not a circular derivation.

full rationale

Flotilla is an empirical systems paper. Its central claims—modular composition of five FL strategies, client/server fault tolerance, scaling to 1080 clients, and resource usage competitive with Flower, OpenFL and FedML—are established by direct measurement on real Pi, Jetson and Docker clusters, not by deriving a quantity from an input that already contains it. No parameter is fitted to a subset of the data and then reported as a prediction: final accuracies, failover times, checkpoint overheads and scaling percentages are observed outcomes. The five strategies (FedAvg, FedAsync, TiFL, HACCS, FedAT) are taken from the external literature and re-implemented through the paper's stated interfaces; this is not a re-labeling of a known result as a new one. Self-citations ([44], [45]) are peripheral pointers to prior group work and are not load-bearing. Two caveats affect the strength, not the circularity, of the claims. First, Sec. 3.5 concedes that the Redis-persisted state 'may be a partial state' and that restored modules 'need to estimate the consistency of the keys they wish to use,' yet Sec. 4.4.1 exercises failover only with FedAvg on CCNN/IID data; this limits the demonstrated generality of the resilience claim but is not circular because the measured sub-second failover is a real empirical event. Second, in Sec. 4.6.2 the paper 'incorporated Flotilla's dataloader into Flower,' which makes the memory comparison partly a control for the dataloader rather than a fully independent evaluation of Flower; this is a fairness caveat, not a derivation by construction. Therefore there is no significant circularity.

Assumptions & free parameters 5 free parameters · 5 assumptions · 0 invented entities

The paper introduces no new physical or mathematical entities. The free parameters listed are configuration choices the authors selected by hand and that directly affect the measured resilience, scalability, and comparison numbers. The axioms are background assumptions about deployment infrastructure and about the fidelity of the implemented strategies.

free parameters (5)
  • Heartbeat interval and missed heartbeat threshold = 5s interval, 5 missed heartbeats
    Chosen by the authors; determines that client failures are detected in about 30s and shapes the resilience and overhead results in Sec 4.4.
  • gRPC training timeout multiplier = 1.5x slowest client round time
    Hand-set default in Sec 4.1.2; affects how quickly failed clients are counted and therefore round time and failure tolerance.
  • Client fraction selected per round = 11% Pi, 50% Jetson, 10% Docker-208, ~9% Docker-1080
    Set per cluster in Sec 4.2; affects training progress, round time, and the scalability comparison.
  • Disk checkpoint interval = every 5 rounds
    Default in Sec 4.1.2; determines how many rounds can be lost on server failure and the checkpointing overhead in Sec 4.4.2.
  • FedAsync mixing hyperparameter = 0.9
    Set in Table 6; influences FedAsync convergence but is a strategy configuration, not a fitted constant for the framework claim.
assumptions (5)
  • domain assumption Clients are directly accessible from the server for gRPC calls.
    Stated in Sec 3.6; if clients sit behind NAT or firewall, the described invocation model needs modification.
  • domain assumption The MQTT broker and external Redis store are reliable and reachable.
    Client discovery and server failover depend on these infrastructure components; Sec 3.6 and 3.5 assume a well-known broker and durable KV store.
  • domain assumption The server is trusted and clients are not malicious.
    Security and privacy are declared non-goals in Sec 2.2.4, so the resilience and correctness claims assume no adversarial behavior.
  • ad hoc to paper Partial, externally persisted state can be used to resume a session without built-in consistency guarantees.
    Sec 3.5 acknowledges the persisted state may be partial on mid-round failure and says modules must estimate consistency; the failover claim depends on this assumption holding for the implemented strategies.
  • domain assumption The five FL strategies implemented in Flotilla faithfully represent the published TiFL, HACCS, FedAT, FedAsync, and FedAvg algorithms.
    The comparison in Sec 4.3 interprets performance differences as properties of the strategies, which requires fidelity of the authors' implementations.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Flotilla: A scalable, modular and resilient federated learning framework for heterogeneous resources." pith.science (2026). https://pith.science/paper/J7HZYIXI

@misc{pith2026250702295,
  author       = {Pith},
  title        = {Pith review of: Flotilla: A scalable, modular and resilient federated learning framework for heterogeneous resources},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/J7HZYIXI}},
  note         = {Machine review of arXiv:2507.02295}
}
read the original abstract

With the recent improvements in mobile and edge computing and rising concerns of data privacy, Federated Learning(FL) has rapidly gained popularity as a privacy-preserving, distributed machine learning methodology. Several FL frameworks have been built for testing novel FL strategies. However, most focus on validating the learning aspects of FL through pseudo-distributed simulation but not for deploying on real edge hardware in a distributed manner to meaningfully evaluate the federated aspects from a systems perspective. Current frameworks are also inherently not designed to support asynchronous aggregation, which is gaining popularity, and have limited resilience to client and server failures. We introduce Flotilla, a scalable and lightweight FL framework. It adopts a ``user-first'' modular design to help rapidly compose various synchronous and asynchronous FL strategies while being agnostic to the DNN architecture. It uses stateless clients and a server design that separates out the session state, which are periodically or incrementally checkpointed. We demonstrate the modularity of Flotilla by evaluating five different FL strategies for training five DNN models. We also evaluate the client and server-side fault tolerance on 200+ clients, and showcase its ability to rapidly failover within seconds. Finally, we show that Flotilla's resource usage on Raspberry Pis and Nvidia Jetson edge accelerators are comparable to or better than three state-of-the-art FL frameworks, Flower, OpenFL and FedML. It also scales significantly better compared to Flower for 1000+ clients. This positions Flotilla as a competitive candidate to build novel FL strategies on, compare them uniformly, rapidly deploy them, and perform systems research and optimizations.

Figures

Figures reproduced from arXiv: 2507.02295 by the authors.

Figure 1
Figure 1. A typical federated learning round on a central server with clients [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. The lifecycle of Federated Learning application, from development to [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Flotilla Architecture 3 Flotilla Architecture [PITH_FULL_IMAGE:figures/full_fig_p013_3.png] view at source ↗
Figures from the paper (10 more)
Figure 4
Figure 4. Figure 4: Flotilla Training Lifecycle showing event triggers between phases and read-only (green) and read/write (orange) states accessible to each module. data, or across different data present in the same set of client. This can improve resource efficiency and throughput of FL…
Figure 5
Figure 5. Figure 5: Sequence diagram of interactions between Leader modules and clients [PITH_FULL_IMAGE:figures/full_fig_p016_5.png]
Figure 6
Figure 6. Figure 6: Using Flotilla’s external state store to resume a training session on server failure. A client failure can be detected at several points of the FL lifecycle: missing a certain number of heartbeats before or during participation in a training round, failure when invokin…
Figure 7
Figure 7. Figure 7: Changes in accuracy with wallclock time and FL rounds for MobileNet on Jetson cluster and CCNN on Pi cluster for IID (rows 1 and 4) and non-IID (rows 2, 3 and 5) data distribution using five FL strategies implemented in Flotilla. The accuracies are averaged over 5 roun…
Figure 8
Figure 8. Figure 8: Changes in accuracy with FL rounds for MobileNet on Dirichlet-based non-IID data using FedPer strategy, using Flotilla in simulation mode. 35% and shows rapid improvement within eight rounds, after which it continues to stabilize around ≈ 75%. This also highlights the …
Figure 9
Figure 9. Figure 9: Time and accuracy performance for all FL strategies, models and clus [PITH_FULL_IMAGE:figures/full_fig_p030_9.png]
Figure 10
Figure 10. Figure 10: Flotilla resilience with server failure and its overheads. repeated several times. In the second setup (failover), we kill the Leader Service on the primary GPU1 after 5 rounds but restore the session on the secondary GPU2 to resume training; and again kill the servic…
Figure 11
Figure 11. Figure 11: Training accuracy achieved with clients failing with Poisson distri [PITH_FULL_IMAGE:figures/full_fig_p033_11.png]
Figure 12
Figure 12. Figure 12: Scaling experiments comparing Flower (FLWR) and [PITH_FULL_IMAGE:figures/full_fig_p035_12.png]
Figure 13
Figure 13. Figure 13: CPU (top row) and Memory (middle row) usage and per-round times (bottom row) for clients while performing local training, during FL of CCNN/CIFAR10-IID/FedAvg using FedML (FLM), Flower (FLWR), OpenFL (OFL) and Flotilla (FLT). Columns indicate the 3 device types in the…

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

76 extracted references · 69 canonical work pages

  1. [1]

    Williams, I

    P. Williams, I. K. Dutta, H. Daoud, M. Bayoumi, A survey on security in internet of things with a focus on the impact of emerging technologies, IEEE IoT-J (2022)

    work page 2022

  2. [2]

    Kumar, P

    S. Kumar, P. Tiwari, M. Zymbler, Internet of things is a revolutionary approach for future technology enhancement: a review, J. Big Data (2019)

    work page 2019

  3. [3]

    J. R. Elias, R. Chard, J. A. Libera, I. Foster, S. Chaudhuri, The manufac- turing data and machine learning platform: Enabling real-time monitoring and control of scientific experiments via iot, in: IEEE WF-IoT-J, 2020. 39

    work page 2020

  4. [4]

    V. J. Aski, V. S. Dhaka, A. Parashar, I. Rida, et al., Internet of things in healthcare: A survey on protocol standards, enabling technologies, wban architectures and open issues, PHYCOM (2023)

    work page 2023

  5. [5]

    M. Ali, G. Lavanya Devi, R. Neelapu, Intelligent traffic signal control sys- tem using machine learning techniques, in: ICMEET, 2021

    work page 2021

  6. [6]

    P. Jain, S. C. Coogan, S. G. Subramanian, M. Crowley, S. Taylor, M. D. Flannigan, A review of machine learning applications in wildfire science and management, Environ. Rev. (2020)

    work page 2020

  7. [7]

    Kononenko, Machine learning for medical diagnosis: history, state of the art and perspective, Artif

    I. Kononenko, Machine learning for medical diagnosis: history, state of the art and perspective, Artif. Intell. Med. (2001)

    work page 2001

  8. [8]

    L. Liu, J. Zhang, S. Song, K. B. Letaief, Client-edge-cloud hierarchical federated learning, in: ICC, 2020

    work page 2020

Show all 76 references
  1. [9]

    Nguyen, M

    T. Nguyen, M. T. Thai, Preserving privacy and security in federated learn- ing, IEEE/ACM Trans. Netw. (2024)

    2024

  2. [10]

    D. C. Nguyen, Q. Pham, P. N. Pathirana, M. Ding, A. Seneviratne, Z. Lin, O. A.Dobre, W. Hwang, Federated learning for smart healthcare: A survey, ACM Comput. Surv. (2023)

    2023

  3. [11]

    G. Long, Y. Tan, J. Jiang, C. Zhang, Federated learning for open banking, in: Federated Learning: Privacy and Incentive, 2020

    2020

  4. [12]

    H. B. McMahan, E. Moore, D. Ramage, S. Hampson, B. A. y Arcas, Communication-efficient learning of deep networks from decentralized data, in: AISTATS, 2016

    2016

  5. [13]

    H. T. Nguyen, V. Sehwag, S. Hosseinalipour, C. G. Brinton, M. Chiang, H. Vincent Poor, Fast-convergent federated learning, IEEE JSAC (2021)

    2021

  6. [14]

    A. M. Abdelmoniem, A. N. Sahu, M. Canini, S. A. Fahmy, Refl: Resource- efficient federated learning, in: EuroSys, 2023

    2023

  7. [15]

    Ching, X

    C.-W. Ching, X. Chen, T. Kim, B. Ji, Q. Wang, D. Da Silva, L. Hu, Totoro: A scalable federated learning engine for the edge, in: EuroSys, 2024

    2024

  8. [16]

    A. F. Khan, A. A. Khan, A. M. Abdelmoniem, S. Fountain, A. R. Butt, A. Anwar, Float: Federated learning optimizations with automated tuning, in: EuroSys, 2024

    2024

  9. [17]

    Z. Chai, A. Ali, S. Zawad, S. Truex, A. Anwar, N. Baracaldo, Y. Zhou, H. Ludwig, F. Yan, Y. Cheng, Tifl: A tier-based federated learning system, in: HPDC, 2020

    2020

  10. [18]

    Wolfrath, N

    J. Wolfrath, N. Sreekumar, D. Kumar, Y. Wang, A. Chandra, Haccs: heterogeneity-aware clustered client selection for accelerated federated learning, in: IPDPS, 2022. 40

    2022

  11. [19]

    C. Xie, S. Koyejo, I. Gupta, Asynchronous federated optimization, arXiv preprint arXiv:1903.03934 (2019)

    2019 arXiv

  12. [20]

    Z. Chai, Y. Chen, A. Anwar, L. Zhao, Y. Cheng, H. Rangwala, Fedat: A high-performance and communication-efficient federated learning system with asynchronous tiers, in: SC, 2021

    2021

  13. [21]

    Zhang, X

    X. Zhang, X. Zhu, J. Wang, H. Yan, H. Chen, W. Bao, Federated learning with adaptive communication compression under dynamic bandwidth and unreliable networks, Inf. Sci. (2020)

    2020

  14. [22]

    F. Lai, Y. Dai, S. Singapuram, J. Liu, X. Zhu, H. Madhyastha, M. Chowd- hury, Fedscale: Benchmarking model and system performance of federated learning at scale, in: ICML, 2022

    2022

  15. [23]

    org/federated/federated_learning (2020)

    Google, Tensorflow—federated learning, https://www.tensorflow. org/federated/federated_learning (2020)

    2020

  16. [24]

    Caldas, S

    S. Caldas, S. M. K. Duddu, P. Wu, T. Li, J. Konečn` y, H. B. McMahan, V. Smith, A. Talwalkar, Leaf: A benchmark for federated settings, arXiv preprint arXiv:1812.01097 (2018)

    2018 arXiv

  17. [25]

    D. J. Beutel, T. Topal, A. Mathur, X. Qiu, J. Fernandez-Marques, Y. Gao, L.Sani, K.H.Li, T.Parcollet, P.P.B.deGusmão, etal., Flower: Afriendly federated learning research framework, arXiv preprint arXiv:2007.14390 (2020)

    2020 arXiv

  18. [26]

    Foley, M

    P. Foley, M. J. Sheller, B. Edwards, S. Pati, W. Riviera, M. Sharma, P. N. Moorthy, S.-h. Wang, J. Martin, P. Mirhaji, P. Shah, S. Bakas, Openfl: the open federated learning library, Phys. Med. Biol. (2022)

    2022

  19. [27]

    C. He, S. Li, J. So, X. Zeng, M. Zhang, H. Wang, X. Wang, P. Vepakomma, A. Singh, H. Qiu, et al., Fedml: A research library and benchmark for federated machine learning, arXiv preprint arXiv:2007.13518 (2020)

    2020 arXiv

  20. [28]

    Bonawitz, H

    K. Bonawitz, H. Eichner, W. Grieskamp, D. Huba, A. Ingerman, V. Ivanov, C. Kiddon, J. Konečný, S. Mazzocchi, B. McMahan, T. Van Overveldt, D. Petrou, D. Ramage, J. Roselander, Towards federated learning at scale: System design, in: Proceedings of Machine Learning and Systems, 2019

    2019

  21. [29]

    Vahidian, M

    S. Vahidian, M. Morafah, M. Shah, B. Lin, Rethinking data heterogeneity in federated learning: Introducing a new notion and standard benchmarks, IEEE TAI (2023)

    2023

  22. [30]

    Pfeiffer, M

    K. Pfeiffer, M. Rapp, R. Khalili, J. Henkel, Federated learning for com- putationally constrained heterogeneous devices: A survey, ACM Comput. Surv. (2023)

    2023

  23. [31]

    A. M. Abdelmoniem, C.-Y. Ho, P. Papageorgiou, M. Canini, A compre- hensive empirical study of heterogeneity in federated learning, IEEE IoT-J (2023). 41

    2023

  24. [32]

    H. Zeng, T. Zhou, Y. Guo, Z. Cai, F. Liu, Fedcav: Contribution-aware model aggregation on distributed heterogeneous data in federated learning, in: ICPP, 2021

    2021

  25. [33]

    X. Li, K. Huang, W. Yang, S. Wang, Z. Zhang, On the convergence of fedavg on non-iid data, in: ICLR, 2019

    2019

  26. [34]

    A. M. Abdelmoniem, M. Canini, Towards mitigating device heterogeneity in federated learning via adaptive model quantization, in: EuroMLSys, 2021

    2021

  27. [35]

    M. Ye, X. Fang, B. Du, P. C. Yuen, D. Tao, Heterogeneous federated learning: State-of-the-art and research challenges, ACM Comput. Surv. (2023)

    2023

  28. [36]

    W. Wu, L. He, W. Lin, R. Mao, C. Maple, S. A. Jarvis, Safa: A semi- asynchronous protocol for fast federated learning with low overhead, IEEE Trans. Comput. (2019)

    2019

  29. [37]

    Y. Cai, W. Xi, Y. Shen, Y. Peng, S. Song, J. Zhao, High-efficient hier- archical federated learning on non-iid data with progressive collaboration, Future Gener. Comput. Syst. (2022)

    2022

  30. [38]

    Zhang, Y

    W. Zhang, Y. Zhao, F. Li, H. Zhu, A hierarchical federated learning algo- rithm based on time aggregation in edge computing environment, Applied Sciences (2023)

    2023

  31. [39]

    A. G. Roy, S. Siddiqui, S. Pölsterl, N. Navab, C. Wachinger, Braintorrent: A peer-to-peer environment for decentralized federated learning, arXiv preprint arXiv:1905.06731 (2019)

    2019 arXiv

  32. [40]

    Ryffel, A

    T. Ryffel, A. Trask, M. Dahl, B. Wagner, J. Mancuso, D. Rueckert, J. Passerat-Palmbach, A generic framework for privacy preserving deep learning, arXiv preprint arXiv:1811.04017 (2018)

    2018 arXiv

  33. [41]

    C. Xu, Y. Qu, Y. Xiang, L. Gao, Asynchronous federated learning on het- erogeneous devices: A survey, Comput. Sci. Rev. (2023)

    2023

  34. [42]

    T. Wolf, L. Debut, V. Sanh, J. Chaumond, C. Delangue, A. Moi, P. Cistac, T. Rault, R. Louf, M. Funtowicz, J. Davison, S. Shleifer, P. von Platen, C. Ma, Y. Jernite, J. Plu, C. Xu, T. L. Scao, S. Gugger, M. Drame, Q. Lhoest, A. M. Rush, Transformers: State-of-the-art natural la...

    2020

  35. [43]

    M. Y. Wang, Deep graph library: Towards efficient and scalable deep learn- ing on graphs, in: ICLR, 2019

    2019

  36. [44]

    Naman, Y

    P. Naman, Y. Simmhan, Optimizing federated learning using remote em- beddings for graph neural networks, in: Euro-Par, 2024. 42

    2024

  37. [45]

    Baheti, S

    S. Baheti, S. Badiger, Y. Simmhan, Violet: An emulation environment for validating iot deployments at large scales, ACM Trans. Cyber-Phys. Syst. (2021)

    2021

  38. [46]

    Bonawitz, V

    K. Bonawitz, V. Ivanov, B. Kreuter, A. Marcedone, H. B. McMahan, S. Pa- tel, D. Ramage, A. Segal, K. Seth, Practical secure aggregation for privacy- preserving machine learning, in: ACM CCS, 2017

    2017

  39. [47]

    Zhang, S

    C. Zhang, S. Li, J. Xia, W. Wang, F. Yan, Y. Liu, BatchCrypt: Efficient homomorphic encryption for Cross-Silo federated learning, in: USENIX ATC, 2020

    2020

  40. [48]

    M. Wu, D. Ye, J. Ding, Y. Guo, R. Yu, M. Pan, Incentivizing differentially private federated learning: A multidimensional contract approach, IEEE IoT-J (2021)

    2021

  41. [49]

    D. Cao, S. Chang, Z. Lin, G. Liu, D. Sun, Understanding distributed poi- soning attack in federated learning, in: 2019 IEEE 25th International Con- ference on Parallel and Distributed Systems (ICPADS), 2019

    2019

  42. [50]

    X.Liu, H.Li, G.Xu, Z.Chen, X.Huang, R.Lu, Privacy-enhancedfederated learning against poisoning adversaries, IEEE Transactions on Information Forensics and Security (2021)

    2021

  43. [51]

    Y. Wang, T. Zhu, W. Chang, S. Shen, W. Ren, Model poisoning defense on federated learning: A validation based approach, in: Network and System Security, 2020

    2020

  44. [52]

    Zhuang, Y

    W. Zhuang, Y. Wen, S. Zhang, Smart multi-tenant federated learning, arXiv preprint arXiv:2207.04202 (2022)

    2022 arXiv

  45. [53]

    Bhuyan, S

    N. Bhuyan, S. Moharir, Multi-model federated learning, in: 2022 14th In- ternational Conference on COMmunication Systems & NETworkS (COM- SNETS), 2022

    2022

  46. [54]

    Kabir, Z

    E. Kabir, Z. Song, M. R. Ur Rashid, S. Mehnaz, Flshield: A validation based federated learning framework to defend against poisoning attacks, in: 2024 IEEE Symposium on Security and Privacy (SP), 2024

    2024

  47. [55]

    J. Frey, T. Tannenbaum, M. Livny, I. Foster, S. Tuecke, Condor-g: a com- putation management agent for multi-institutional grids, in: HPDC, 2001

    2001

  48. [56]

    M. Hu, D. Wu, Y. Zhou, X. Chen, M. Chen, Incentive-aware autonomous client participation in federated learning, TPDS (2022)

    2022

  49. [57]

    Luoto, K

    A. Luoto, K. Systä, Fighting network restrictions of request-response pat- tern with mqtt, IET Software (2018)

    2018

  50. [58]

    LeCun, L

    Y. LeCun, L. Bottou, Y. Bengio, P. Haffner, Gradient-based learning ap- plied to document recognition, Proc. IEEE (1998). 43

    1998

  51. [59]

    Sandler, A

    M. Sandler, A. Howard, M. Zhu, A. Zhmoginov, L.-C. Chen, Mobilenetv2: Inverted residuals and linear bottlenecks, in: CVPR, 2018

    2018

  52. [60]

    K. He, X. Zhang, S. Ren, J. Sun, Deep residual learning for image recogni- tion, CVPR (2016)

    2016

  53. [61]

    Y. Yao, W. Jin, S. Ravi, C. Joe-Wong, Fedgcn: Convergence- communication tradeoffs in federated training of graph convolutional net- works, NeurIPS (2024)

    2024

  54. [62]

    Hamilton, Z

    W. Hamilton, Z. Ying, J. Leskovec, Inductive representation learning on large graphs, NeurIPS (2017)

    2017

  55. [63]

    J. Deng, W. Dong, R. Socher, L.-J. Li, K. Li, L. Fei-Fei, Imagenet: A large-scale hierarchical image database, CVPR (2009)

    2009

  56. [64]

    Yurochkin, M

    M. Yurochkin, M. Agarwal, S. Ghosh, K. Greenewald, N. Hoang, Y. Khaz- aeni, Bayesian nonparametric federated learning of neural networks, in: ICML, 2019

    2019

  57. [65]

    A.Z.Tan, H.Yu, L.Cui, Q.Yang, Towardspersonalizedfederatedlearning, IEEE Transactions on Neural Networks and Learning Systems (2023)

    2023

  58. [66]

    M. G. Arivazhagan, V. Aggarwal, A. K. Singh, S. Choudhary, Feder- ated learning with personalization layers, arXiv preprint arXiv:1912.00818 (2019)

    2019 arXiv

  59. [67]

    A.J.Lemoine, M.L.Wenocur, Onfailuremodeling, Navalresearchlogistics quarterly (1985)

    1985

  60. [68]

    Dwork, Differential privacy, in: International colloquium on automata, languages, and programming, Springer, 2006

    C. Dwork, Differential privacy, in: International colloquium on automata, languages, and programming, Springer, 2006

    2006

  61. [69]

    A. Das, T. Castiglia, S. Wang, S. Patterson, Cross-silo federated learning for multi-tier networks with vertical and horizontal data partitioning, ACM Trans. Intell. Syst. Technol. (2022)

    2022

  62. [70]

    Y. Tan, G. Long, L. LIU, T. Zhou, Q. Lu, J. Jiang, C. Zhang, Fedproto: Federated prototype learning across heterogeneous clients, AAAI (2022)

    2022

  63. [71]

    Zhang, Y

    J. Zhang, Y. Liu, Y. Hua, J. Cao, Fedtgp: Trainable global prototypes with adaptive-margin-enhanced contrastive learning for data and model heterogeneity in federated learning, AAAI (2024)

    2024

  64. [72]

    Z. Lian, J. Cao, Q. Cao, W. Liu, Z. Zhu, X. Zhou, Nebulafl: Self-organizing efficient multilayer federated learning framework with adaptive load tun- ing in heterogeneous edge systems, IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems (2024). 44

    2024

  65. [73]

    L. Liu, J. Zhang, S. Song, K. B. Letaief, Client-edge-cloud hierarchical federated learning, in: ICC 2020 - 2020 IEEE International Conference on Communications (ICC), 2020

    2020

  66. [74]

    L. Yuan, Z. Wang, L. Sun, P. S. Yu, C. G. Brinton, Decentralized feder- ated learning: A survey and perspective, IEEE Internet of Things Journal (2024)

    2024

  67. [75]

    M. Zhou, G. Liu, K. Lu, R. Mao, H. Liao, Accelerating the decentralized federated learning via manipulating edges, in: Proceedings of the ACM Web Conference 2024, 2024

    2024

  68. [76]

    W. Zhu, Z. Liu, Z. Chen, C. Shi, X. Zhang, S. Guo, Fedvalidate: A ro- bust federated learning framework based on client-side validation, 2023 8th International Conference on Data Science in Cyberspace (DSC) (2023). 45 A Psuedocode for FedAt and TiFL inFlotilla A.1 FedAT Pseudo...

    2023

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.