Type
Feature
Description
We are conducting a comparative study of Federated Learning strategies for NIDS (Network Intrusion Detection Systems) under Non-IID conditions, building on the work in this paper using Flower. As part of this effort, we have implemented several new FL strategies in Flower, and we'd like to contribute one of them back: FLAD (https://github.com/doriguzzi/flad-federated-learning-ddos).
FLAD departs significantly from traditional strategies like FedAvg: among the other differences, instead of selecting clients randomly and running a fixed number of rounds, it drives client selection and early stopping based on the F1 score metric. Because of this, we were unable to implement FLAD by deriving it from Flower's Strategy abstract class — its start() method would need a different signature and a fundamentally different implementation.
This raises a question for the maintainers: would you be interested in an implementation of FLAD that doesn't conform to the standard Strategy interface, given its inherently different logic? Or is the expectation that all new strategies, including ones like FLAD, must be derived from the base Strategy class as described in the Flower documentation?
We'd appreciate guidance on the preferred path before submitting a PR.
Planned Implementation
No response
Additional Context
No response
Type
Feature
Description
We are conducting a comparative study of Federated Learning strategies for NIDS (Network Intrusion Detection Systems) under Non-IID conditions, building on the work in this paper using Flower. As part of this effort, we have implemented several new FL strategies in Flower, and we'd like to contribute one of them back: FLAD (https://github.com/doriguzzi/flad-federated-learning-ddos).
FLAD departs significantly from traditional strategies like FedAvg: among the other differences, instead of selecting clients randomly and running a fixed number of rounds, it drives client selection and early stopping based on the F1 score metric. Because of this, we were unable to implement FLAD by deriving it from Flower's Strategy abstract class — its start() method would need a different signature and a fundamentally different implementation.
This raises a question for the maintainers: would you be interested in an implementation of FLAD that doesn't conform to the standard Strategy interface, given its inherently different logic? Or is the expectation that all new strategies, including ones like FLAD, must be derived from the base Strategy class as described in the Flower documentation?
We'd appreciate guidance on the preferred path before submitting a PR.
Planned Implementation
No response
Additional Context
No response