Surviving the Edge: Federated Learning under Networking and Resource Constraints Mike Mwanje, Okemawo Obadofin, Theophilus Benson, Joao Barros
arXiv:2605.03870v1 [cs.NI] 5 May 2026
College of Engineering, Carnegie Mellon University Africa, Kigali, Rwanda Emails: {mmwanje, oobadofi, theophib, jbarros}@andrew.cmu.edu.
Abstract—Motivated by the growing proliferation of federated learning (FL) in edge environments, we present the first systematic characterization of transport-layer breaking points in FL systems operating under conditions of highly constrained network and compute resources. Using a reproducible testbed with chaos engineering tools, we evaluate Flower under progressively degraded network conditions representative of resourceconstrained deployments in Africa and similar environments. Our empirical investigation reveals a fundamental mismatch between FL’s burst-idle communication pattern and standard TCP connection management. We identify precise operational boundaries: FL training catastrophically fails at 5-second oneway latency due to TCP handshake timeouts, above 50% packet loss due to buffer exhaustion, and with 90% client dropout rates. Through systematic analysis of connection patterns during training rounds, we demonstrate that FL’s periodic model update bursts, separated by extended local training periods, violate the assumptions underlying default TCP configurations. To validate the significance of these findings, we show that adjusting just three TCP connection management parameters can significantly reduce training time under extreme latency — proving that transport-layer awareness is not merely beneficial but essential for FL deployment at the network edge. Our characterization methodology and findings provide practitioners with concrete thresholds for determining when standard FL deployments will fail and when advanced reliability techniques become necessary. Index Terms—federated learning, network resilience, edge computing, distributed machine learning
I. I NTRODUCTION Rapid advancements in Artificial Intelligence (AI) and Machine Learning (ML) have led to an unprecedented demand for computational resources [1]. As AI/ML continue evolving, the existing hardware struggles to meet the growing demand. One way to meet this demand is to exploit the vast number of Internet of Things (IoT) devices that exist at the network edge. Individually, devices such as low-end smart phones, Raspberry Pis, and wireless sensor nodes, have limited potential, but their collective processing power can substantially bridge this computational gap. Moreover, the desire to train AI models on edge devices locally in Africa leads us to address unique challenges regarding connectivity. Regions such as Africa face high latencies, frequent internet shutdowns [2], This publication was developed as part of a program managed by Carnegie Mellon University Africa and supported by the Mastercard Foundation. The views expressed in this document are solely those of the authors and do not necessarily reflect those of Carnegie Mellon University Africa or the MasterCard Foundation.
TABLE I C OMPARISON OF AVERAGE NETWORK LATENCIES ACROSS CONTINENTS (A DAPTED FROM [5]) Continent
Average Latency (ms)
Africa N. America Europe Asia Australia
280 45 30 60 50
and unstable power supply [3], which together limit device availability for Federated Learning (FL) [4]. As seen in Table I, which summarizes network latencies across continents [5], Africa experiences significantly higher latencies which in some instances go even beyond 400ms. These extreme conditions are not merely outliers but represent real scenarios faced in various African regions. While significant research has focused on algorithmic improvements to FL, the transport layer’s role remains largely unexplored. Practitioners cannot make informed deployment decisions or know when advanced reliability methods are necessary without understanding where and why FL frameworks break under network stress, which is critical as FL expands into resource-constrained environments where standard assumptions often do not hold [6]. This paper investigates the possibility of using FL effectively and efficiently when leveraging edge devices that must operate under extreme conditions. We outline our key contributions as follows: Methodology for performance evaluation. We designed and implemented a testbed for the rigorous evaluation of FL systems. It uses Kubernetes containers to emulate resourceconstrained edge clients and integrates chaos engineering tools, to systematically inject high latency and packet loss. This facilitates the reproducible analysis of FL performance and resilience under network conditions representative of challenging real-world deployments. Characterization of FL resilience. We conducted a systematic empirical study to define the operational boundaries of a prominent FL framework, Flower [7]. By subjecting it to progressively extreme network conditions, including network latencies up to 10 seconds and packet loss rates up to 50%, we demonstrate that while the framework exhibits initial robustness, performance degrades substantially under sustained network stress. Our findings quantify the tipping points beyond which effective training becomes untenable.
TABLE II N ETWORK M ETRICS : A FRICA (U RBAN /RURAL ) VS . G LOBAL AVERAGE Metric
Africa
Latency (ms) Packet Loss (%) Internet Shutdowns
Fig. 1. Architecture of the Flower Federated Learning Platform (Taken from Flower’s Documentation [7]).
Transport-layer root cause analysis and validation. Our investigation reveals that FL’s performance degradation stems from a fundamental mismatch between its burst-idle communication pattern and standard TCP connection management, explaining why FL gRPC-based frameworks fail at specific thresholds. We validate this finding’s significance by demonstrating that adjusting just three TCP parameters (tcp syn retries, tcp keepalive time, tcp keepalive intvl) restores training capability where default configurations fail, confirming that transport-layer awareness is essential for FL resilience. II. BACKGROUND AND M OTIVATION Federated learning is an ML technique that enables training models on distributed datasets across multiple devices without exchanging the raw data. Instead of centralizing the data for training, FL allows each participating node to keep its data locally while collaboratively learning a shared model by exchanging only model updates [6]. Although the most common industry use is to maintain data privacy, FL can be used to obtain data parallelism to aggregate several edge devices for training a model jointly, which would otherwise be impossible or take a lot of time using a single edge device. We use Flower, an end-to-end FL framework that stands out due to its scalability, agnosticism, heterogeneity support, extensibility, and seamless [8], [9]. Flower’s architecture (Figure 1) comprises: (1) A Server: Manages the global model, coordinates training rounds, and aggregates model updates from clients to update the global model. (2) Clients: Perform local training on their individual data and send model updates to the server. The framework’s core components include a ClientManager for handling client connections, an FL loop for coordinating the learning process, and a customizable Strategy abstraction for implementing specific FL algorithms [7]. Africa faces significant challenges with network performance and reliability, often due to underdeveloped infrastruc-
Urban
Rural
100–300 5–10 Frequent
500–3000 10–30 Severe
Global
50–100 <1 Rare
ture and frequent outages. While telecom operators initially designed network technologies to tolerate maximum latencies of 300ms and 10% packet loss in remote areas [10], much of the infrastructure is now ageing, leading to inconsistent connectivity during peak usage hours. This degradation is exacerbated by chronic power supply issues, where frequent electricity outages disrupt internet service providers and data centers, limiting consistent internet access [3]. Furthermore, the region is plagued by a massive deficit in compute resources. Despite housing approximately 18% of the global population, Africa accounts for less than 1% of the world’s total data center capacity [11]. Finally, infrastructural limitations are worsened by political instability and interference, such as state-sanctioned internet blackouts during periods of unrest or elections [12]. These challenges manifest in poor network performance metrics across the continent, particularly in rural areas. Table II illustrates the stark contrast between network conditions in Africa and global averages. The disparity in data centre capacity further exacerbates these network issues. For context, South Africa, leading the continent with about 100 data centres, has only 200MW of computing power, comparable to Switzerland, a much smaller country population-wise. This capacity shortage is projected to increase, with demand expected to exceed supply by 300%, driven by growth in cloud technologies, startups, mobile financial services, and AI deployment [11]. In this study, we extend our experiments to test latencies as high as 10 seconds and packet loss up to 80% to evaluate FL performance under adverse network conditions to discover where it breaks. By pushing the system to its breaking point, we can identify the specific failure modes, and lay the groundwork for developing robust optimization strategies that make FL truly practical for deployment in constrained environments. Communication in FL is periodic — occurring only at the end of each local training round. Assuming 10 clients, the total data transfer per round is approximately 3 MB. If updates are transmitted over 10 seconds, the required bandwidth per client is about 0.24 Mbps, with an aggregate bandwidth of 2.4 Mbps for all clients. Additionally, the asynchronous nature of FL allows clients to send updates independently, avoiding bandwidth bottlenecks that could arise with synchronous communication. It is for these reasons that our focus remains on latency, availability, and packet loss, which have the most impact on the performance of FL environments. III. R ELATED W ORK The most closely related works [13], [14] explore the difficulties of training and deploying AI models in resource-
constrained environments like Africa. However, these studies typically focus on niche applications within individual countries. In contrast, our study addresses a broader infrastructural problem by systematically analyzing a wide range of network profiles observed across the continent. By evaluating this diverse spectrum of network conditions, we identify the exact failure points where advanced reliability methods provided by complementary works [6] are required. Furthermore, large-scale open-source initiatives like TinyML primarily focus on optimizing AI inference on constrained hardware. Our work instead examines the systems-level challenge of training models on limited devices over highly volatile networks. While related mobile Federated Learning (FL) approaches, such as Alibaba’s Walle, address on-device training, they generally assume devices with stronger compute capabilities and relatively stable connectivity. Consequently, these existing frameworks largely overlook the severe spectrum of network degradation that our study systematically evaluates. Many existing large-scale open source projects, e.g., TinyML, focus on optimizing AI inference within constrained devices. Our study explores an organizational problem, i.e training models on constrained devices in terrible networks. Related approaches on FL on mobile devices, e.g., Alibaba’s Walle, generally focus on devices with stronger compute specs. These works often overlook the spectrum of network profiles that we examine. There is a growing body of work on enhancing the model training aspect of FL to address a range of resource constraints from compute and network to client data and availability. These approaches provide a complementary solution to our recommendations. Similarly, work [15] which explores the feasibility and performance of FL on non-independent and identically distributed data, provides alternative designs to address the challenges we highlight in our study. While prior studies on communication-efficient FL focus on model aggregation or compression algorithms, they generally assume a stable and transparent transport substrate. Our work differs fundamentally: we expose and quantify transport-level fragilities that arise even before model aggregation begins, highlighting the need for protocol-aware FL architectures. IV. C HARACTERIZING FL R ESILIENCE We begin by describing our experimental setup used for analysis, then we discuss our evaluation of Flower’s behavior under ,latency and packet loss, and client failure. A. Experimental Setup We designed an experimental testbed that enables controlled, reproducible investigation of FL network resilience, which we used in our analysis. The platform provides a fault-injection environment comparable to large-scale network systems testbeds while maintaining full control over latency, loss, and client failure parameters. The testbed scales to tens of clients and is designed to be extensible for future FL benchmarking. We run the FL server and FL clients on two
Fig. 2. Federated learning test-bed
separate networks, set up such that there was 0% packet loss and a latency of less than 5 ms to minimize noise in our results. Given the separate networks, we could create controlled network outages. As seen in Figure 2, clients run inside a containerized environment in Kubernetes, which simplifies management and collection of key metrics: network traffic, CPU, and RAM. In configuring the clients, our goal was to allocate resources matching the lowest specification of Raspberry Pi, a 700 MHz BCM2835 model with 512 MB of RAM. To do this, we configured each client with 0.5 vCPU 1 . To introduce network variability, we used Linux NetEm which provides control over network delays, packet loss, and bandwidth limitations 2 . This involved introducing variability at the server’s networking interface to enable uniform control across the various clients. Client failures were introduced using Chaos-Mesh, a chaos engineering tool for Kubernetes, enabling us to programmatically introduce client (pod) failures. To evaluate our experiments, we focus on two key metrics: Accuracy, which captures the model’s prediction performance as reported by the Flower framework, and Training time, defined as the total duration required to complete a predefined number of training rounds. B. Network and Client Resilience By introducing high latencies, significant packet loss, and frequent client dropouts, we can identify critical thresholds where performance degrades. Latency. In Figure 3, we present the results from varying the network latency. We observe that below 5,000ms, the key impact of increased latency is increased training time. Latency greater than 5,000ms results in no training. In analyzing the code base we observe that this is due to a set of timeouts at the transport layer which shut down connections with significantly high latency. This is particularly problematic because Linux shuts down the connection at the start and thus prevents any communication, thus no training. 1 1 vCPU corresponds to 1 core running at 1 - 1.4 GHz, thus 0.5 vCPU provides a fair approximation of the Pi B’s 1-core running at 700 MHz [16]. 2 We fixed the limit (queue size) to 200
Fig. 3. Impact of latency Fig. 5. Impact of client failure rate TABLE III S UMMARY OF VIRTUAL ENVIRONMENT FAULT TEST RESULTS Category
Acceptable
Tolerable
Failure
Network Delay (s) Packet Loss (%) Client Failure Rate (%)
< 0.3 < 10 < 50
5 30 - 40 50 - 70
>5 > 50 > 90
Recommendation #3 – Flower’s resilience to client failures can be increased by lowering the minimum fit/evaluation configuration settings. Fig. 4. Impact of packet loss
Recommendation #1 – Increase the default OS and framework timeout limits to tolerate extreme latency. Packet loss. From Figure 4, we observe three key trends: (1) Low packet loss (below 30%) has no impact because the TCP contains mechanisms to re-transmit packets, effectively recovering from packet loss. (2) As packet loss increases from 30% to 50%, the model accuracy decreases by 0.3% and training time increases by 220%. We observe that given the magnitude of the loss, even the retransmitted packets are lost which delays recovery. (3) The loss over 50% results in the failure of Flower to train the model. Further analysis reveals that at such high loss rates, the buffers used to store packets while waiting for the lost packets do run out of space. Recommendation #2 – Training failure due to packet loss can be addressed by increasing the system’s buffer, although it can significantly increase model training times. Client Failure. Figure 5 shows the impact of pod failure on FL model training time, and accuracy. We observe no significant impact in accuracy when less than 90% of the clients failed. Setting the minimum fit and evaluation set to 10% allows Flower to continue training the model when at least 10% of the clients are available thus tolerating 90% client failure rate. However, the training time did increase by 23% because it took longer to converge with fewer clients.
Table III provides a summary of our analysis and characterizes regions of network performance and client outages that are acceptable, tolerable, or cause total failure. We believe that such findings can be useful to operators and developers in understanding how Flower behaves in specific environments. The tolerable region can be extended by altering Flower and/or Linux configurations to facilitate continued training in extreme conditions, the cost being longer training times. V. TCP PARAMETER T UNING Network protocol design often treats layers in isolation [17]. Having identified the transport-layer as the root cause of FL failures under extreme conditions, we validate our findings by testing if TCP parameter tuning can extend operational boundaries. Flower alongside many other FL frameworks rely on TCP for the reliable delivery of messages. This dependency prompted us to explore the TCP parameters available in the network configuration directory. Our goal was to identify specific settings that could validate our hypothesis regarding the benefits of cross-layer optimization. Table IV lists the parameters we investigated, along with a brief description of the functionality each one controls [18]. Based on these findings, we modified our experimental testbed to include scripts that explore unique values set for each parameter, testing ranges that spanned the lower and upper bounds of the default values. Packet Loss. Tuning retransmission and buffer parameters had a negligible effect under packet loss. This was attributed to the distinct communication characteristics of FL workloads compared to traditional high-bandwidth applications. TCP parameters are primarily designed to optimize sustained data
TABLE IV TCP M ANAGEMENT PARAMETERS E XPLORED TCP Parameter
Description
tcp_syn_retries tcp_synack_retries tcp_keepalive_time tcp_keepalive_intvl tcp_retries2 tcp_rmem/tcp_wmem tcp_max_syn_backlog tcp_sack tcp_window_scaling
Maximum initial SYN retransmits. Maximum SYN-ACK response retransmits. Idle time before keepalive probes. Interval between keepalive probes. Established connection retransmission limit. Regulates socket buffer sizes. Maximum queued connection requests. Enables selective packet acknowledgments. Enables large TCP windows.
Fig. 8. The impact of different tcp_keepalive_intvl values on latency
Fig. 6. The impact of different tcp_syn_retries values on latency
transfers with large payloads [19], whereas FL communication consists of small, bursty model updates. Latency. While testing latency values, we discovered three critical TCP parameters that provided substantial improvements when compared to baseline performance using their default system values. As observed in Figures 6, 7, and 8 our experiments with tcp_syn_retries, tcp_keepalive_time, and tcp_keepalive_intvl revealed variable performance gains under high-latency network conditions. In Figure 6, we can observe the impact of varying tcp_syn_retries in high-latency environments. Setting the default system value yielded suboptimal training time performance for 10 out of 17 data points (nearly 60% of the
time). For example, at latencies between 200ms and 600ms, the default tcp_syn_retries value of 6 consistently resulted in suboptimal training times. We can also observe a similar trend repeated in Figure 7. For 11 out of the 17 data points (approximately 65% of cases), setting the default system value for the tcp_keepalive_time (7200) also resulted in longer training times. We can observe an example of this inconsistent performance at latencies between 0ms and 400ms in the figure. Finally, Figure 8 also highlights the same trend, the default setting of 75 seconds consistently fails to deliver the best overall performance for FL workloads. 12 out of 17 data points (over 70% of our measurements) yielded reduced training times when the default tcp_keepalive_intvl values were set. Based on our evaluation, we attribute the behaviors observed in our experiments to the following underlying transport-layer dynamics: Connection Establishment Resilience (tcp syn retries) FL clients must establish reliable connections with the central server at the beginning of each training round. Under high-latency conditions (>100ms), the default tcp syn retries value of 6 often proves insufficient, leading to premature connection failures during the critical handshake phase. Connection Maintenance (tcp keepalive time/intvl) The periodic nature of FL communication creates unique challenges for connection management. Unlike traditional web applications with continuous data streams, FL workloads exhibit bursty communication patterns during model update transmission, extended idle periods during local training phases, and sensitivity to connection drops that can invalidate entire training rounds. VI. D ISCUSSION AND F UTURE W ORK
Fig. 7. The impact of different tcp_keepalive_time values on latency
Our study positions transport-layer adaptability as a firstclass design axis in FL systems and other related applications of distributed systems [20]. These results suggest that FL frameworks should expose network-awareness hooks at runtime, allowing integration with adaptive transport modules. By treating the transport layer as part of the learning system,
we shift the focus from training efficiency alone to communication resilience as a design primitive. Since prominent FL frameworks such as Flower, FATE and PySyft rely on a gRPCbased network stack, the TCP inefficiencies we identified herein likely represent a systemic issue for the broader FL ecosystem. Building on these insights, our ongoing work is exploring several promising avenues to create more resilient and efficient FL systems: Alternative Transport Protocols: We are investigating modern transport protocols, particularly QUIC, as a promising alternative to TCP for FL workloads due to its flexible congestion control algorithms. Because prominent FL frameworks like Flower rely heavily on gRPC, transitioning from TCP to QUIC could resolve many issues we observed. Furthermore, as highlighted by recent industry efforts [21], modern gRPC deployments are increasingly leveraging dynamic configurations to auto-adjust in response to varying latencies in real time. We plan to integrate these principles, allowing the FL transport layer to dynamically optimize its parameters based on live network conditions. Comparative Analysis of FL Frameworks. To understand if the observed transport-layer inefficiencies are universal, we are extending our testbed to benchmark other popular FL frameworks such as FATE and PySyft to determine whether our findings are specific to Flower’s gRPC implementation or represent a more fundamental challenge for all FL systems relying on traditional network stacks. Adaptive TCP Tuning Daemon. We propose the design of an adaptive connection management daemon that would monitor comprehensive connection state metrics to dynamically optimize TCP parameters based on real-time network conditions. Generalizing Across Diverse Datasets. The efficacy of our scheme has been demonstrated on the MNIST dataset [22]. To guarantee its broader applicability, we are currently evaluating our cross-layer optimizations on a wider range of datasets, including more complex image data. VII. C ONCLUSION Deploying Federated Learning systems in resourceconstrained environments such as those found in Africa, presents a significant challenge due to unreliable networks and limited client availability. We empirically identified transportlayer bottlenecks limiting FL resilience and showed that modest TCP tuning restores stability, motivating cross-layer co-design of future FL systems. This work reveals a previously underexplored dependency between FL performance and transport-layer configuration, motivating the design of adaptive, cross-layer network architectures for edge learning. Our results and methodology lay the foundation for future systems that co-design learning, transport, and connectivity, enabling FL to operate reliably in the most resource-constrained environments. R EFERENCES [1] Z. Jia, J. Chen, X. Xu, J. Kheir, J. Hu, H. Xiao, S. Peng, X. S. Hu, D. Chen, and Y. Shi, “The importance of resource awareness in artificial
intelligence for healthcare,” Nature Machine Intelligence, vol. 5, no. 7, pp. 687–698, 2023. [2] CIPESA, “https://cipesa.org/wp-content/files/reports/SIFA23 report.pdf,” accessed: 2026-02-18. [Online]. Available: https: //cipesa.org/wp-content/files/reports/SIFA23 Report.pdf [3] M. Agoundedemba, C. K. Kim, and H.-G. Kim, “Energy status in africa: Challenges, progress and sustainable pathways,” Energies, vol. 16, no. 23, 2023. [4] H. B. McMahan, E. Moore, D. Ramage, S. Hampson, and B. A. y Arcas, “Communication-efficient learning of deep networks from decentralized data,” International Conference on Artificial Intelligence and Statistics, 2016. [5] A. Formoso, J. Chavula, A. Phokeer, A. Sathiaseelan, and G. Tyson, “Deep diving into africa’s inter-country latencies,” IEEE International Conference on Computer Communications, pp. 2231–2239, 2018. [6] K. Bonawitz, H. Eichner, W. Grieskamp, D. Huba, A. Ingerman, V. Ivanov, C. Kiddon, J. Konečnỳ, S. Mazzocchi, B. McMahan et al., “Towards federated learning at scale: System design,” in Proceedings of machine learning and systems, vol. 1, 2019, pp. 374–388. [7] D. Beutel, T. Topal, A. Mathur, X. Qiu, T. Parcollet, and N. Lane, “Flower: A friendly federated learning research framework,” 07 2020. [8] P. Riedel, L. Schick, R. Von Schwerin, M. Reichert, D. Schaudt, and A. Hafner, “Comparative analysis of open-source federated learning frameworks - a literature-based survey and review,” International Journal of Machine Learning and Cybernetics, Jun. 2024. [9] M. V. Luzón, N. Rodrı́guez-Barroso, A. Argente-Garrido, D. JiménezLópez, J. M. Moyano, J. Del Ser, W. Ding, and F. Herrera, “A tutorial on federated learning from theory to practice: Foundations, software frameworks, exemplary use cases, and selected trends,” IEEE/CAA Journal of Automatica Sinica, vol. 11, no. 4, pp. 824–850, 2024. [10] M. Zheleva, P. Schmitt, M. Vigil, and E. Belding, “The increased bandwidth fallacy: performance and usage in rural zambia,” in Proceedings of the 4th Annual Symposium on Computing for Development, 2013. [11] “Africa’s data centre growth opportunity,” https://aiimafrica.com/media/ media-centre/africas-data-centre-growth-opportunity/, accessed: 202602-18. [12] J. Rydzak, M. Karanja, and N. Opiyo, “Internet shutdowns in africa— dissent does not die in darkness: Network shutdowns and collective action in african countries,” International Journal of Communication, vol. 14, p. 24, 2020. [13] J. Fabila, V. M. Campello, C. Martı́n-Isla, J. Obungoloch, K. Leo, A. Ronald, and K. Lekadir, “Democratizing ai in africa: Federated learning for low-resource edge devices,” in Medical Information Computing. Springer Nature Switzerland, 2025, pp. 101–109. [14] A. Gwagwa, E. Kraemer-Mbula, N. Rizk, I. Rutenberg, and J. De Beer, “Artificial intelligence (AI) deployments in Africa: benefits, challenges and policy dimensions,” The African Journal of Information and Communication, vol. 26, pp. 1–28, 2020. [15] Q. Li, Y. Diao, Q. Chen, and B. He, “Federated learning on non-iid data silos: An experimental study,” 2022 IEEE 38th international conference on data engineering (ICDE), pp. 965–978, 2022. [16] “Raspberry pi board overview,” accessed: 2026-02-18. [Online]. Available: https://static.raspberrypi.org/files/products/Board Overview. pdf [17] M. Chiang, S. H. Low, A. R. Calderbank, and J. C. Doyle, “Layering as optimization decomposition: Questions and answers,” 2006 IEEE Military Communications conference, pp. 1–10, 2006. [18] “Linux manual page - tcp(7),” accessed: 2026-02-18. [Online]. Available: https://man7.org/linux/man-pages/man7/tcp.7.html [19] S. Wang, T. Tuor, T. Salonidis, K. K. Leung, C. Makaya, T. He, and K. Chan, “Adaptive federated learning in resource constrained edge computing systems,” IEEE Journal on Selected Areas in Communications, vol. 37, no. 6, pp. 1205–1221, 2019. [20] O. Obadofin and J. Barros, “Network hexagons under attack: Secure crowdsourcing of georeferenced data,” 2025 IEEE Security and Privacy Workshops (SPW), pp. 206–212, 2025. [21] “GRPC HTTP/3 - key benefits and implementation considerations,” https://www.catchpoint.com/http2-vs-http3/grpc-http3, accessed: 202602-18. [22] Y. Lecun, L. Bottou, Y. Bengio, and P. Haffner, “Gradient-based learning applied to document recognition,” Proceedings of the IEEE, vol. 86, no. 11, pp. 2278–2324, Nov. 1998.