Reply to Reviewer's Comment (Continued)
*Q2-c: You mentioned "ELSA and PBFL and SecureFL rely on the unrealistic assumption of two non-colluding parties", RFLPA just put those computation tasks on the clients, maybe that is more unfriendly for the clients (mobile or other edge devices). Existed works can be extended to multi-parties using shamir secret sharing.*
Firstly, extending existing works (ELSA, PBFL, and SecureFL) to multi-parties requires significant changes on the algorithm, and that should be another solution/direction to be explored.
Furthermore, **our framework can be easily adapted to the case considering the heterogeneous computation power of each client**. For example, the server can select the clients with more computation power to participate in the round 2 & 3 & 4. In that way, clients with weaker computing power could merely generate the secret shares of their local gradients and upload them to the server. This can be achieved by simply limiting the participating client in round 2 & 3 & 4 to the computation powerful clients, thereby improving the user experience for edge devices with low computation power.
*Q2-d: Experimental comparison under WAN/LAN setting*
Firstly, **performing experiment under WAN/LAN setting is unnecessary since the communication time is mainly determined by the message size**. In WAN, the extra communication time for multiple rounds of communication mainly comes from latency, i.e., the time it takes for a message to travel from the sender to the receiver. The latency is negligible compared to the time it takes to transfer the message. Specifically, the latency in WAN setting ranges from 20ms to 700ms (within 1 seconds) depending on the geographical distance. On the other hand, the time to transfer the message (ignoring latency in WAN setting) is around 6.4 seconds for RFLPA, and 52 seconds for BREA, assuming 100 clients using a 1.6MB classifier and 100 Mbps per client. Therefore, the latency from multiple communication rounds is much smaller than the time RFLPA reduced for smaller message size.
Furthermore, many existing SecAgg algorithms (focusing only on privacy protection) also rely on multiple communication rounds. For instance, [1] and [2] leverages 4 communication rounds per iteration. Our framework is able to integrate defense against poisoning attack into SecAgg using the same communication rounds as [1] and [2].
Overall, we sincerely hope that our explanations could address the reviewer's further concerns.
[1] Bonawitz, K., Ivanov, V., Kreuter, B., Marcedone, A., McMahan, H. B., Patel, S., ... & Seth, K. (2017, October). Practical secure aggregation for privacy-preserving machine learning. In proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (pp. 1175-1191).
[2] Bell, J. H., Bonawitz, K. A., Gascón, A., Lepoint, T., & Raykova, M. (2020, October). Secure single-server aggregation with (poly) logarithmic overhead. In Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security (pp. 1253-1269).