# Multi-FedLS: a Framework for Cross-Silo Federated Learning Applications on
Multi-Cloud Environments

Rafaela C. Brum<EMAIL_ADDRESS>Maria Clicia Stelling de Castro
<EMAIL_ADDRESS>Luciana Arantes<EMAIL_ADDRESS>Lúcia Maria de A.
Drummond<EMAIL_ADDRESS>Pierre Sens<EMAIL_ADDRESS>
###### Abstract

Federated Learning (FL) is a distributed Machine Learning (ML) technique that
can benefit from cloud environments while preserving data privacy. We propose
Multi-FedLS, a framework that manages multi-cloud resources, reducing
execution time and financial costs of Cross-Silo Federated Learning
applications by using preemptible VMs, cheaper than on demand ones but that
can be revoked at any time. Our framework encloses four modules: Pre-
Scheduling, Initial Mapping, Fault Tolerance, and Dynamic Scheduler. This
paper extends our previous work [1] by formally describing the Multi-FedLS
resource manager framework and its modules. Experiments were conducted with
three Cross-Silo FL applications on CloudLab and a proof-of-concept confirms
that Multi-FedLS can be executed on a multi-cloud composed by AWS and GCP, two
commercial cloud providers. Results show that the problem of executing Cross-
Silo FL applications in multi-cloud environments with preemptible VMs can be
efficiently resolved using a mathematical formulation, fault tolerance
techniques, and a simple heuristic to choose a new VM in case of revocation.

###### keywords:

Federated learning , Multi-cloud , Resource management

††journal: Journal of Parallel and Distributed Computing

[uff]organization=Fluminense Federal University, addressline=Av. Gal. Milton
Tavares de Souza, s/nº, São Domingos, city=Niterói, state=Rio de Janeiro,
country=Brazil [su]organization=Sorbonne Université, LIP6, CNRS, addressline=4
Place Jussieu, postcode=75005, city=Paris, country=France
[uerj]organization=State University of Rio de Janeiro, addressline=Rua São
Francisco Xavier, 524, Maracanã, city=Rio de Janeiro, state=Rio de Janeiro,
country=Brazil

##  1 Introduction

Proposed by McMahan  _et al._ [2], Federated Learning (FL) is a distributed
machine learning (ML) technique where the participants (clients)
collaboratively train a ML model without sharing their respective private data
[3]. Since there is an increasing concern with data privacy, particularly with
current data protection laws (_e.g._ GPDR111https://gdpr-info.eu/ in Europe),
FL is an extremely interesting and promising approach.

Denoted Model-Centric Federated Learning [4], FL has a client-server
architecture where each client trains the model locally and communicates only
the model weights to the central server which keeps the current global model.
The server is responsible for receiving all client weights, updating the
global model, and communicating the new model weights to the clients.

The model-centric FL can be classified into two types: Cross-Device FL,
composed of a large number of clients which are low-powered devices, like
mobile phones [2] or IoT devices [5], and Cross-Silo FL, composed of a few but
powerful clients, usually companies or institutions, with similar datasets
willing to create a central model with private large dataset repositories,
denoted silos. Note that in Cross-Device FL, the set of clients can strongly
vary over the execution, while in Cross-Silo FL, all clients can be considered
to be available during the whole execution since they are machines with high-
performance capabilities or even clusters.

In Cross-Silo FL applications, the scheduling and resource provisioning
problems can be related to the scheduling of distributed Machine Learning (ML)
applications [6, 7, 8] as there is the assumption that the clients’ jobs are
always available. On the other hand, it is worth pointing out that there are
two main differences between scheduling distributed ML and FL: (i) in
distributed ML, the scheduler assumes that all clients have the same amount of
data, and (ii) clients can share data among themselves.

Training ML algorithms require an enormous amount of data, often stored using
cloud storage services [9, 10, 11]. These services are part of the
Infrastructure-as-a-Service (IaaS) model offered by a cloud provider and they
can vary in performance and costs. Usually, the IaaS services include storage,
Virtual Machines (VMs) with different accelerators, and different network
bandwidths depending on the cloud provider.

This work focuses on Cross-Silo Federated Learning for multi-cloud platforms
where clients’ silos are kept in different storage repositories, which provide
data privacy guarantees and availability.

A multi-cloud platform is composed of one or more cloud providers that offer
multiple choices of virtual machine types in independent and isolated
geographic regions222https://aws.amazon.com/about-aws/global-
infrastructure/,333https://cloud.google.com/about/locations, with different
execution and communication times and costs. Hence, in order to have efficient
executions of FL applications on a multi-cloud platform, the good choice of
cloud resource allocation is imperative. Wrong ones may increase execution
cost and time [12, 13].

Therefore, assuming datasets previously allocated in one or more storage
systems of different cloud providers, the question is how to select the most
suitable virtual machines to execute the clients and the server in a multi-
cloud platform in order to minimize execution time and financial costs.

Aiming at solving this resource management problem, two of our previous works
[14, 1] proposed the multi-cloud framework Multi-FedLS which is composed by
the Pre-Scheduling and Initial Mapping modules. The Pre-Scheduling module
executes several tests with a dummy application to obtain slowdown metrics,
which are then used by the Initial Mapping module to define a first static
scheduling of the tasks.

The above works considered that Multi-FedLS consists of one or more cloud
providers whose VMs are never revoked neither fail. However, in order to
reduce monetary costs, the allocation of spot (preemptible) VMs should be
considered since they are offered with a high discount. On the other hand,
such VMs can be revoked at any time by the respective cloud provider. Since an
FL application is a long-running one, Multi-FedLS should (1) periodically save
the computed weights of both the server and clients in a stable storage and
(2) be able to restart the weight computing task in a new VM, if the one in
which the task executes revokes or fails. Considering these two features, the
current work extends the Multi-FedLS framework presented in [14, 1] by adding
to it two new modules: the Fault Tolerance and the Dynamic Scheduler. The
former implements a checkpoint mechanism while the latter reconfigures the
Initial Mapping, also choosing a new VM to replace the revoked or failed one
and restarting the corresponding task.

For the sake of scalability, performance experiments were carried out on
CloudLab [15], a platform that provides different types of machines in various
U.S. states, emulating a multi-cloud environment and then on a real two-cloud
platform composed of Amazon Web Services (AWS) and Google Cloud Provider
(GCP). We have evaluated Multi-FedLS with a use-case application, which
classifies tomography images into with or without tumor lymphocytes, and two
FL benchmark datasets.

The paper is organized as follows. Section 2 introduces the related work.
Section 3 describes the application and environment models used in Multi-
FedLS. Section 4 shows the Multi-FedLS architecture using a Flower-based
framework. Results from experiments on both CloudLab and the AWS-GCP
environment are presented and discussed in Section 5. Section 6 concludes the
work and proposes some future research directions.

##  2 Related Work

Since the first FL algorithm [2], many resource management optimizations, such
as the selection of just a fraction of client tasks in each scheduling
communication round [16, 17, 18], or new aggregation strategies [19, 20] have
been proposed. However, they are effective for Cross-Device FL which has a
huge number of clients.

To the best of our knowledge, there are few papers on Cross-Silo FL and none
of them focus on resource management of tasks but just on FL solutions
specific to given applications [21, 22, 23].

There exist several works about resource management on clouds (using single or
multi-clouds) [24, 25, 26, 27, 28, 29, 30, 31, 32]. Some propose using
spot/preemptible VMs to reduce costs and handle possible revocations of these
VMs [24, 25, 26, 29, 30]. However, most of them focus on Bag-of-Tasks
applications, and others consider communication between tasks in their
solution [24, 29] using only AWS as the cloud provider and do not assume any
synchronization barrier.

Our scheduling problem consists in finding the optimal placement for each
client and the server of an FL application, which has synchronization barriers
along the execution, aiming at minimizing the execution and financial costs.
Since our proposal is not tailored for any particular Cross-Silo FL
application, it does not explore server aggregation approaches for a specific
ML model.

Based on the above points, works on scheduling distributed ML applications,
especially those that take into account stragglers [6], network performance
[7], or locality awareness [8] are related to ours.

During the distributed ML training, Amiri  _et al._ consider in [6] that,
among the workers, there exist transient stragglers. To handle them, the
authors divide the central dataset into $n$ small chunks, assuming that each
worker will compute over a number of them sequentially. Then, the server sends
each piece to multiple workers and waits for $k$ results from different
chunks, $k\leq n$. We should point out that in FL scenarios, the data exchange
between tasks is prohibitive to preserve privacy.

Liu  _et al._ consider switches that need to reconfigure themselves to send
data in both directions saving energy. They proposed two scheduling policies
for distributed ML training jobs execution. Besides handling possible network
contention, the authors assume that all workers have the same dataset size and
computational power, which are not always the case in FL scenarios.

Respecting some resource and locality-aware constraints, Yu  _et al._ [8]
formulate an optimization model which allocates different distributed ML jobs
into a set of physical machines. Despite the locality-aware scheduling
problem, the work has assumptions that cannot be applied to FL scenario: a
central server dataset, frequency of communication between tasks much higher
than the Cross-Silo FL one, and the co-location of tasks which might help
malicious FL clients discover private information of the others [33].

Regarding the execution of FL applications in clouds, there are few works
tackling this problem in the literature [34, 35, 21]. However, most of them
use the cloud as part of their proposed architecture [34, 35] not as the
environment to execute the FL application. The work of Rajendran  _et al._
[21] is the only one that runs an FL approach in a cloud environment. Their
results were implemented models in a scenario with two clients in a simulated
environment and on the Microsoft Azure Cloud Databricks [36], an open-source
tool for data engineering and collaborative data science, to exchange the ML
model between two institutions. In our work, we not only use clouds as the
execution environment but we select the VMs to reduce costs and execution
time, handling eventual failures raised by spot ones.

Papers handling distributed Machine Learning on Clouds usually use cloud
services as a tool to evaluate their scheduling proposal [6, 8] or to verify
the central dataset integrity [37]. To the best of our knowledge, there are a
few research papers that consider the features of Cloud Computing to propose
their solution [38, 39, 40, 41].

Zhang  _et al._ [38] consider spot (or preemptible) cloud instances to train
distributed ML tasks and study the convergence of classical algorithms to
distributed ML training when the number of workers varies. Duong and Quang
[39, 40] present FC2, a system to execute distributed ML jobs into on-demand
instances of a cloud provider. In [41], Wagenländer  _et al._ propose Spotnik
to deal with preemptive VM instance revocations. The authors assume a
decentralized training approach in which the workers communicate with each
other in a predefined ring pattern to aggregate their results ignoring faults
and privacy.

However, the above papers assume an equal division of the central dataset
among workers, using a single region to allocate all cloud resources. Such an
approach reinforces the point that data privacy and heterogeneity, which are
essential in Federated Learning, are not a concern in distributed ML.

##  3 Application and Environment models

A Federated Learning application is composed of one server $s$ and a set of
clients $C$. It is also divided into well-defined steps called communication
rounds (or rounds) with communication barriers between them. Each
communication round has two phases: the training and the evaluation one.

The training phase starts by the server $s$ sending a message
$s\\_msg_{train}$ which has the initial model weights to all clients. After
receiving the weights, each client $c_{i}\in C$ updates its respective local
model and starts training it, using its local dataset. When the training
finishes, the client sends back a message $c\\_msg_{train}$ with the updated
model weights. By the time the server receives $c\\_msg_{train}$ messages from
all clients, it aggregates the weights and then starts the evaluation phase by
sending a message $s\\_msg_{aggreg}$ with the aggregated weights to all
clients. Similarly to the training phase, upon reception of the latter, a
client updates its local model. Finally, the client evaluates its local model
with its dataset and sends back the ML metrics in a $c\\_msg_{test}$ message
to the server that, after receiving and aggregating the metrics from all
clients, starts a new round.

Regarding the environment, we consider that $P$ is the set of available cloud
providers, each provider $p_{j}\in P$ has a set of regions $R_{j}$, and the
cost $cost\\_t_{j}$ (in $ per GB) to send any message from one VM in $p_{j}$
to any other VM is constant. Typically, a provider $p_{j}$ offers a limited
number of GPUs ($N\\_GPU_{j}$) and vCPUs ($N\\_CPU_{j}$). Additionally, in
each region $r_{jk}\in R_{j}$, the number of available GPUs and vCPUs is
restricted ($N\\_L\\_GPU_{jk}$ and $N\\_L\\_CPU_{jk}$, respectively).
Moreover, each region $r_{jk}\in R_{j}$ contains a set of available VM
instance types, $V_{jk}$, that can be executed in it, and each $vm_{jkl}\in
V_{jk}$ contains a number of vCPUs, $cpu_{jkl}$, and a number of GPUs,
$gpu_{jkl}$, with a fixed cost (in $ per second) $cost_{jkl}$.

Note that some variables of the application and environment models were
defined in our previous work [1].

##  4 Multi-FedLS architecture

This section describes the architecture of Multi-FedLS. It is composed of four
modules, described in the following, and uses the FL tool Flower [42]. The
latter provides a unified API to create Federated Learning applications whose
execution can take place in both real-world and simulated scenarios with any
ML framework underneath it. Flower can execute in several environments with
different operating systems and hardware settings. Due to its modular
structure, the user only needs to implement a few functions for transforming a
regular ML application into a federated one.

Our framework takes advantage of the communication rounds of an FL
application. In our previous works [14, 1, 43, 44, 45], we evaluated a use-
case application running on two commercial clouds, Amazon Web Services (AWS)
and Google Cloud Provider (GCP). We observed that every round, except the
first one, has similar execution times. Thus, we assume that all rounds have
similar execution times reducing our problem of scheduling and managing the
resources for the whole FL application as a single FL round.

Figure 1 shows the proposed architecture for the Multi-FedLS framework. It
consists of four main modules: Pre-Scheduling, Initial Mapping, Fault
Tolerance with monitoring, and Dynamic Scheduler.

Figure 1: Architecture of Multi-FedLS. Afapted from [14]

###  4.1 Pre-Scheduling module

The Pre-Scheduling module executes several tests with a dummy application to
obtain two slowdown metrics, as described in previous papers [14, 1]. Used as
an input for the Initial Mapping, the metrics are: (1) the communication
slowdown $sl\\_comm_{jklm}$ between every pair of regions $r_{jk}$ and
$r_{lm}$ and (2) the execution slowdown $sl\\_inst_{jkl}$ in each VM
$vm_{jkl}$ of the environment. We define communication (resp., execution)
slowdown as the ratio between the communication time between a pair of regions
(resp., execution time in a VM) and the time in a chosen baseline pair of
regions (resp., baseline VM).

Once the two metrics have been computed, it is not necessary to re-execute the
dummy application in every framework execution, but only when there is a
change in the regions or the VMs in the environment.

The baseline values for the current FL job are also computed by the Pre-
Scheduling module. These values are (1) the execution time of each client in
the baseline VM and (2) the message exchange time of the job model in the
baseline pair of regions. The execution time of a client $c_{i}$ is divided
into the training execution time $train\\_bl_{i}$ and test execution time
$test\\_bl_{i}$. The message exchange time is also divided into training and
test, where $train\\_comm\\_bl$ and $test\\_comm\\_bl$ are the time spent
sending messages during the training and the test respectively.

###  4.2 Initial Mapping module

The Initial Mapping module starts by calculating the expected communication
and computation times of the current FL job of all pair of regions and VMs.
The communication time $t\\_comm_{jklm}$ between regions $r_{jk}$ of provider
$p_{j}$ and $r_{lm}$ of provider $p_{l}$ and the computation time
$t\\_exec_{ijkl}$ of client $c_{i}$ in VM $vm_{jkl}$ are given by Equation 1
and Equation 2 respectively.

$t\\_comm_{jklm}=(train\\_comm\\_bl+test\\_comm\\_bl)\times sl\\_comm_{jklm}$

(1)

$t\\_exec_{ijkl}=(train\\_bl_{i}+test\\_bl_{i})\times sl\\_inst_{jkl}$

(2)

The complexity of scheduling tasks in distributed computing resources is
proven to be NP-complete [46], which makes it challenging even in simple
scenarios. Furthermore, the features of multi-clouds increase the difficulty
to solve the problem. As a result, we have modeled our scheduling problem as a
Mixed-Integer Linear Programming problem with two objectives: to minimize the
total execution time (makespan) and the monetary cost. Additionally, the
scheduling solution should comply with two constraints: the deadline (T) and
the budget (B), as specified by the user. As we assume that the FL application
executes through $n_{rounds}$ with similar execution times, we obtain the
maximum budget ($B_{round}$) and deadline ($T_{round}$) of a round by dividing
$B$ and $T$ by $n_{rounds}$. Consequently, the scheduling problem can be
formulated for a single round.

The mathematical formulation, which minimizes both the execution time and the
costs of the FL jobs running in the clouds, solved by the Initial Mapping, is
detailed in our previous work [1]. Usually, the most expensive VMs of a cloud
take less time to execute. Thus, having conflicting objectives, we apply a
user-defined weight value to create a single objective problem. Table 1
summarizes the notation and variables used in Multi-FedLS.

Table 1: Notation and variables used in our framework. Name | Description
---|---
$C$ | Set of clients in the FL application
$P$ | Set of available cloud providers
$p_{j}$ | A cloud provider
$R_{j}$ |  Set of regions available in provider $p_{j}$
$r_{jk}$ |  A region of provider $p_{j}$
$V_{jk}$ |  Set of instance types available in region $r_{jk}$
$vm_{jkl}$ |  A instance type of region $r_{jk}$
$B_{round}$ | Budget to a single FL round
$T_{round}$ | Deadline to a single FL round
$T_{max}$ | Time of a single FL round
$N\\_GPU_{j}$ |  Number of available GPUs in the provider $p_{j}$
$N\\_CPU_{j}$ |  Number of available vCPUs in the provider $p_{j}$
$cost\\_t_{j}$ |  Cost (in $ per GB) of sending a message from provider $p_{j}$
$N\\_L\\_GPU_{jk}$ |  Number of available GPUs in region $r_{jk}$
$N\\_L\\_CPU_{jk}$ |  Number of available vCPUs in region $r_{jk}$
$cpu_{jkl}$ |  Number of vCPUs in the instance type $vm_{jkl}$
$gpu_{jkl}$ |  Number of GPUs in the instance type $vm_{jkl}$
$cost_{jkl}$ |  Cost (in $ per second) of instance type $vm_{jkl}$
$c_{i}$ | A client of the FL application
$size(s\\_msg_{train})$ | Size of training message sent by the server to a client
$size(s\\_msg_{aggreg})$ | Size of test message sent by the server to a client
$size(c\\_msg_{train})$ | Size of training message sent by a client to the server
$size(c\\_msg_{test})$ | Size of test message sent by a client to the server
$total\\_costs$ | Total financial costs of a single FL round
$t_{m}$ | Total execution time (makespan) of an FL round
$t\\_exec_{ijkl}$ |  Computational time (training and test) of client $c$ in $vm_{jkl}$
$t\\_comm_{jklm}$ |  Communication time (training and test) between regions $r_{jk}$ and $r_{lm}$
$t\\_aggreg_{jkl}$ |  Aggregation time of server in $vm_{jkl}$
$vm\\_costs$ | Total financial cost of all VMs in a single FL round
$comm\\_costs$ | Total financial cost of message exchange within an FL round
$x_{ijkl}$ |  Binary variable which indicates if client $c_{i}$ executes on $vm_{jkl}$ or not
$y_{jkl}$ |  Binary variable which indicates if the server executes on $vm_{jkl}$ or not
$\alpha$ | Weight given by the user for the objectives (ranging from 0 to 1)
$T_{max}$ | Maximum possible makespan regarding all clients and possible VMs
$cost_{max}$ |  Maximum total cost considering $T_{max}$, all possible locations and VMs

The objective function (Equation 3) uses the weight $\alpha$, defined by the
user, to express how much each objective should be taken into account. The
objectives are the makespan of the application, $t_{m}$, and the execution
cost, $total\\_costs$. The latter comprises the VMs cost, $vm\\_costs$, plus
the communication cost, $comm\\_costs$.

$\min\alpha\times total\\_costs+(1-\alpha)\times t_{m}$ (3)

Considering $x_{ijkl}$ (resp., $y_{jkl}$) as the binary variable representing
whether or not a client $c_{i}$ (resp., server $s$) executes on VM $vm_{jkl}$
of region $r_{jk}$ of provider $p_{j}$, the VMs execution and communication
costs are respectively calculated by Equation 4 and Equation 5 where
$cost_{jkl}$ is the fixed cost (in $ per second) to use the VM $vm_{jkl}$ and
$comm_{jm}$ is the cost to send and receive messages between provider $p_{j}$
and $p_{m}$. Note that as described in Equation 6, $j$ can be equal to $m$.

$\leavevmode\resizebox{422.77661pt}{}{$vm\\_costs=\sum_{c_{i}\in
C}\sum_{p_{j}\in P}\sum_{r_{jk}\in R_{j}}\sum_{vm_{jkl}\in
V_{jk}}(x_{ijkl}\times cost_{jkl}$}\\\
\leavevmode\resizebox{422.77661pt}{}{$\times t_{m})\ +\sum_{p_{j}\in
P}{\sum_{r_{jk}\in R_{j}}\sum_{vm_{jkl}\in V_{jk}}(y_{jkl}\times
cost_{jkl}\times t_{m})}$}$ (4)
$\leavevmode\resizebox{446.2658pt}{}{$comm\\_costs=\sum_{c_{i}\in
C}\sum_{p_{j}\in P}\sum_{r_{jk}\in R_{j}}\sum_{vm_{jkl}\in
V_{jk}}\sum_{p_{m}\in P}\sum_{r_{mn}\in R_{m}}$}\\\
\leavevmode\resizebox{258.36667pt}{}{$\sum_{vm_{mno}\in V_{mn}}(x_{ijkl}\times
y_{mno}\times comm_{jm})$}$ (5)
$\leavevmode\resizebox{418.08165pt}{}{$comm_{jm}=(size(s\\_msg_{train})+size(s\\_msg_{aggreg}))\times
cost\\_t_{m}$}\\\
\leavevmode\resizebox{328.82706pt}{}{$+(size(c\\_msg_{train})\
+size(c\\_msg_{test}))\times cost\\_t_{j}$}$ (6)

The monetary cost and the makespan in Equation 3 can have different minimum
and maximum values. Thus, we need to normalize both objectives to have the
same range of 0-1. To this end, we use $T_{max}$ as the maximum possible
makespan of an FL round for the current application in the current sets of
providers, regions, and VMs as well as $cost_{max}$ as the maximum cost in an
FL round, computed as Equation 7. We obtain $cost_{max}$ by the sum of two
following products: (i) the cost of hiring the most expensive VM times both
$T_{max}$ and the number of tasks; and (ii) the most expensive communication
costs between providers ($comm_{jm}$) times the number of clients.

$cost_{max}=\max_{p_{j}\in P,r_{jk}\in R_{j},vm_{jkl}\in
V_{jk}}(cost_{jkl})\times T_{max}\times(|C|+1)\\\ +\max_{p_{j},p_{m}\in
P}(comm_{jm})\times|C|$ (7)

Our mathematical formulation must respect a set of constraints (8 to 16).
Constraints 8 and 9 ensure that our budget and deadline for an FL round are
not violated. Constraints 10 and 11 guarantee that each task executes on a
single VM $vm_{jkl}\in V_{jk}$ in region $r_{jk}\in R_{j}$ of provider
$p_{j}\in P$.

$\displaystyle total\\_costs\leq B_{round}$ (8) $\displaystyle t_{m}\leq
T_{round}$ (9) (10) (11)

The next group of constraints (12 to 15) ensure that the solution does not use
more GPUs and vCPUs per provider than the maximum available bounds.
Constraints 12 and 13 refer to the global provider bounds of available GPUs
and vCPUs respectively while Constraints 14 and 15 refer to the same bounds
but per region.

$\leavevmode\resizebox{446.2658pt}{}{$\sum_{c_{i}\in C}{\sum_{r_{jk}\in
R_{j}}{\sum_{vm_{jkl}\in V_{jk}}x_{ijkl}\times gpu_{jkl}}}+\sum_{r_{jk}\in
R_{j}}\sum_{vm_{jkl}\in V_{jk}}(y_{jkl}$}\\\
\leavevmode\resizebox{187.89912pt}{}{$\times gpu_{jkl})\leq
N\\_GPU_{j},\forall p_{j}\in P$}$ (12)
$\leavevmode\resizebox{446.2658pt}{}{$\sum_{c_{i}\in C}{\sum_{r_{jk}\in
R_{j}}{\sum_{vm_{jkl}\in V_{jk}}x_{ijkl}\times cpu_{jkl}}}+\sum_{r_{jk}\in
R_{j}}\sum_{vm_{jkl}\in V_{jk}}(y_{jkl}$}\\\
\leavevmode\resizebox{187.89912pt}{}{$\times cpu_{jkl})\leq
N\\_CPU_{j},\forall p_{j}\in P$}$ (13)
$\leavevmode\resizebox{446.2658pt}{}{$\sum_{c_{i}\in C}{\sum_{vm_{jkl}\in
V_{jk}}{x_{ijkl}\times gpu_{jkl}}}\ +\sum_{vm_{jkl}\in V_{jk}}{y_{jkl}\times
gpu_{jkl}}$}\\\ \leavevmode\resizebox{234.87749pt}{}{$\leq N\\_L\\_GPU_{jl},\
\forall p_{j}\in P,\forall r_{jk}\in R_{j}$}$ (14)
$\leavevmode\resizebox{446.2658pt}{}{$\sum_{c_{i}\in C}{\sum_{vm_{jkl}\in
V_{jk}}{x_{ijkl}\times cpu_{jkl}}}\ +\sum_{vm_{jkl}\in V_{jk}}{y_{jkl}\times
cpu_{jkl}}$}\\\ \leavevmode\resizebox{234.87749pt}{}{$\leq N\\_L\\_CPU_{jl},\
\forall p_{j}\in P,\forall r_{jk}\in R_{j}$}$ (15)

Constraint 16 ensures that $t_{m}$, the makespan of the FL round, will be at
least equal to the total execution time of each client, which in turn is equal
to the sum of the computational time $t\\_exec_{ijkl}$ of the client in
question, the communication time $t\\_comm_{jklm}$ between this client’s
region and the server, and the aggregation time $t\\_aggreg_{mno}$ of the
server. The domain of the decision variables $x_{ijkl}$ and $y_{jkl}$ are
determined in constraints 17 and 18.

$x_{ijkl}\times
y_{mno}\times(t\\_exec_{ijkl}+t\\_comm_{jkmn}+t\\_aggreg_{mno})\leq
t_{m},\forall c_{i}\in C,\\\ \forall p_{j},p_{m}\in P,\forall r_{jk}\in
R_{j},\forall vm_{jkl}\in V_{jk},\forall r_{mn}\in R_{m},\ \forall vm_{mno}\in
V_{mn}$ (16)

$x_{ijkl}\in\\{0,1\\},\forall c_{i}\in C,\forall p_{j}\in P,\forall r_{jk}\in
R_{j},\forall vm_{jkl}\in V_{jk}$

(17) (18)

###  4.3 Fault Tolerance module

As previously explained, Multi-FedLS takes advantage of preemptible (or spot)
VMs to reduce costs. The main drawback of these VMs is the revocation
possibility at any time. AWS usually sends a two-minute notification to the
selected VM to notify about its revocation while Google Cloud, after only 30
seconds, terminates the VM. Thus, the application must handle possible VM
revocations and internal errors during the execution, which lead to faulty FL
tasks. Note that the failure of a client has a different impact in the FL
execution than the failure of the server.

During the FL execution, the Fault Tolerance module monitors all tasks and
handles eventual VMs revocations and runtime errors. When it detects any
problem, it triggers the Dynamic Scheduler module (described in the next
section) to select a new VM for the faulty task which was running in the
revoked VM, informing if the task is the server or a client. After receiving
from the Dynamic Scheduler the chosen VM to restart the task, the Fault
Tolerance module launches it and continue to monitor all tasks within the FL
application. When all tasks finish, the module stops monitoring the tasks and
starts the VMs termination process.

Flower supports client failures during an FL round by making the server
aggregate only the results received by the non-faulty clients. However, to
start a new round, the FL server waits for a defined minimum number of
available clients, which can be smaller than the total number of clients. In
Cross-Silo FL, there are usually few clients and not considering one of them
at every round can have an impact in the learning outcomes. Thus, the FL
server always waits for all clients to start the next round. There is no need
to manually restart the model at the clients because in the beginning of each
round, the server sends the current weights to all clients (Section 3).

While Flower handles a client’s error smoothly, it does not tolerate the
failure of the server. Furthermore, when it happens, all clients stop their
execution after receiving an error. Multi-FedLS handles possible server
faults, using fault-tolerant techniques on both server and client sides.

Although Flower does not have an automatic way to save the model updates on
the server side, it allows users to modify the server code to implement
checkpointing during the server’s aggregation
phase444https://flower.dev/docs/saving-progress.html. Our framework takes
advantage of this feature by asking the server to checkpoint every $X$ round.
Whenever a new checkpoint is stored on the server’s VM local disk, it is
transferred to another location asynchronously, which can be either a storage
service or an extra VM.

On the client side, the aggregated weights received from the server in each
round are stored in the VM’s local disk, without sending it to another
location. The clients’ checkpoint is only used when the server’s checkpoint is
older than the clients’ one. Thus, to restart the server, it is necessary to
verify if the server or the clients have the latest checkpoint. If it is the
server checkpoint, the saved weights are sent to the new VM before restarting
the server task and the FL server just reads the weights. If it is the client
one, the FL server restarts in the new VM and waits for any client to send its
weights before starting the first round.

###  4.4 Dynamic Scheduler module

We denoted the faulty task as the task that was running in the revoked VM
instance. The Dynamic Scheduler module adapts the objective function of the
mathematical formulation of the Initial Mapping module and uses its value in a
greedy heuristic to choose the new VM for the faulty task. It also takes
advantage of the metrics computed by previous modules. Depending on the type
of the faulty task, the Dynamic Scheduler computes differently the expected
makespan and expected monetary costs, using a new instance to execute the
faulty task. Algorithm 1 computes the new makespan using $t$ as the faulty
task (which can be $s$ for the server or client $c_{i}$) and $vm_{jkl}$ as the
instance to be allocated to task $t$.

Algorithm 1 Makespan Re-calculation

$t,vm_{jkl}$

$max\\_makespan\leftarrow-\infty$

if $t=s$ then{Faulty task is the server}

for $c_{i}\in C$ do

$current\\_vm_{mno}\leftarrow current\\_map_{c_{i}}$

$total\\_time\leftarrow t\\_exec_{imno}+t\\_comm_{mnjk}+t\\_aggreg_{jkl}$

if $total\\_time>max\\_makespan$ then

$max\\_makespan\leftarrow total\\_time$

end if

end for

else {Faulty task is client $c_{t}$}

$current\\_server\\_vm_{mno}\leftarrow current\\_map_{s}$

$max\\_makespan\leftarrow t\\_exec_{tjkl}+t\\_comm_{jkmn}+t\\_aggreg_{mno}$

for $c_{i}\in C\backslash\\{c_{t}\\}$ do

$current\\_vm_{pqr}\leftarrow current\\_map_{c_{i}}$

$total\\_time\leftarrow t\\_exec_{ipqr}+t\\_comm_{pqmn}+t\\_aggreg_{mno}$

if $total\\_time>max\\_makespan$ then

$max\\_makespan\leftarrow total\\_time$

end if

end for

end if

return $max\\_makespan$

The FL round makespan is defined by the client which takes longer to send its
weights to the server. The delay is related to a longer training time and/or
communication time. Thus, the makespan is obtained by computing the higher
time a client needs to train and communicate with the server along with the
server’s aggregation time. If the faulty task is the server, then $vm_{jkl}$
is the new server instance and the loop swaps through all clients $c_{i}\in C$
to compute the total expected execution time of each client and store the
highest one as the new makespan. If the faulty task is a client, the current
server instance is available in variable $current\\_server\\_vm_{mno}$ and the
makespan of the faulty task is computed by using $vm_{jkl}$ as the client’s
instance. Then, the loop swaps through all clients $c_{i}\in C$, excluding the
current task to check if any of the current clients have a higher makespan.

Algorithm 2 shows how to compute the new cost, which receives the same inputs
as the previous algorithm, i.e., the faulty task $t$ and the new instance
$vm_{jkl}$ as well as the makespan in $ms$.

Algorithm 2 Financial Cost Re-calculation

$t,vm_{jkl},makespan$

$total\\_cost\leftarrow 0.0$

if $t=s$ then{Faulty task is the server}

$total\\_cost\leftarrow total\\_cost+cost_{jkl}\times ms$

for $c_{i}\in C$ do

$current\\_vm_{mno}\leftarrow current\\_map_{c_{i}}$

$total\\_cost\leftarrow total\\_cost+cost_{mno}\times ms+comm_{jm}$
{$comm_{jm}$ as Equation 6}

end for

else {Faulty task is client $c_{t}$}

$current\\_server\\_vm_{mno}\leftarrow current\\_map_{s}$

$total\\_cost\leftarrow total\\_cost+cost_{jkl}\times ms+comm_{mj}$
{$comm_{mi}$ as Equation 6}

for $c_{i}\in C\backslash\\{c_{t}\\}$ do

$current\\_vm_{pqr}\leftarrow current\\_map_{c_{i}}$

$total\\_cost\leftarrow total\\_cost+cost_{pqr}\times ms+comm_{mp}$
{$comm_{mp}$ as Equation 6}

end for

end if

return $total\\_cost$

The total cost in a single FL round comprises the execution cost of each task
and message exchange costs of all clients to the server. Thus, in Algorithm 2
the execution cost of the server is firstly computed and then the execution
and message exchange costs of all clients are also computed. The execution
cost of an instance is the multiplication of the makespan and the instance
cost while the message exchange cost is computed using $comm_{jm}$ (Equation
6), the cost to exchange the FL messages between the server’s and the client’s
providers. Equally to the previous algorithm, when the faulty task $t$ is the
server, the server provider $p_{j}$ is obtained from the input instance
$vm_{jkl}$. Otherwise, if the faulty task is a client, the server’s provider
$p_{m}$ is obtained from the current server instance.

Algorithm 3 implements a greedy heuristic for choosing a new instance for a
server or a client after a revocation, receiving as input $t$, the faulty
task, $I_{t}$, the current set of all possible instances for task $t$ and
$old\\_vm_{jkl}$, the current revoked VM instance. Note that if the faulty
task is the server then $t=s$ and $I_{t}=I_{s}$, the set of possible server
instances; otherwise, the task

Algorithm 3 Instance Selection

$t,I_{t},old\\_vm_{jkl}$

$remove\\_vm\\_from\\_set(I_{t},old\\_vm_{jkl})$

$min\\_value\leftarrow\infty$

for each $vm_{mno}\in I_{t}$ do

$makespan\leftarrow computes\\_new\\_makespan(t,vm_{mno})$ {Algorithm 1}

$cost\leftarrow compute\\_expected\\_cost(makespan,t,vm_{mno})$ {Algorithm 2}

$value\leftarrow\alpha\times(cost/cost_{max})+(1-\alpha)\times(makespan/T_{max})$

if $value<min\\_value$ then

$new\\_instance\leftarrow vm_{mno}$

$min\\_value\leftarrow value$

end if

end for

return $new\\_instance$

is client $c_{i}$, then $t=c_{i}$ and $I_{t}=I_{c_{i}}$, the set of possible
instances for client $c_{i}$. Moreover, in the first execution of the Dynamic
Scheduler, $I_{t}$ is the sum of all $V_{jk}$ sets for all regions $r_{jk}\in
R_{j}$ for all providers $p_{j}\in P$.

The first step in Algorithm 3 is to remove the revoked VM from the set of
possible VMs. From previous experiments, we observed that once the instance
type is revoked in a region in AWS, it cannot be reallocated in the same
region immediately [47]. Thus, we assume this behavior to all cloud providers
and remove the $old\\_vm_{jkl}$ from $I_{t}$. Note that we do not use the same
set for all tasks, or not even for all clients, as they can have different
expected execution times which can correspond to different selections in both
Initial Mapping and Dynamic Scheduler modules. After removing the revoked VM,
our algorithm starts the loop iterating on all VMs from $I_{t}$ to select the
VM to restart task $t$. The makespan and cost are computed with Algorithms 1
and 2, respectively, using $vm_{mno}$ as the instance for the task $t$. After
that, the sum of the makespan and cost is done by using the same weight as the
objective function of the Initial Mapping module (Equation 3), $\alpha$ for
the normalized cost and $1-\alpha$ for the normalized makespan.

##  5 Experimental environment and results

This section describes the experimental environment using three different
applications and the obtained results.

###  5.1 Applications

We selected three applications to execute in our framework: a real-world use-
case application and two applications from an FL benchmark. The use-case
application, detailed in [43, 44], identifies Tumor-Infiltrating Lymphocytes
(TILs) in high-resolution human tissue images and generates maps depicting
their spatial distribution. However, the high pixel count (up to
100K$\times$100K) of Whole Slide Tissue Images (WSIs) makes it challenging to
extract information from the thousands of WSIs available. Saltz  _et al._ [48]
developed a deep learning application for TIL classification and analysis that
uses the VGG16 model, a convolutional neural network (CNN) model used for
image recognition. We evaluate Multi-FedLS by focusing on the CNN training
step, assuming that the WSIs have already been classified by experts and
divided into patches. The TIL application has 4 clients with 948 training
samples and 522 test samples each.

The other two applications are from LEAF [49], a hub of benchmarks for
different FL settings, mostly focused on Cross-Device FL (thousands of clients
with few samples). We selected two datasets, the Shakespeare and the FEMNIST
ones, and we adapted them to a Cross-Silo FL setting (fewer clients with more
samples).

The Shakespeare dataset is based on the book The Complete Works of William
Shakespeare, with each character of each play being a different client. We
selected clients with more than 18000 samples combining the training and test
datasets, which left us with 8 clients. Their training datasets vary from
16488 to 26282 samples and their test datasets vary from 1833 to 2921 samples.
This dataset is used to predict the next character in the sentence, and we
implemented the reference model in LEAF [49], which uses an embedding of
dimension 8 and a Long Short Term Memory (LSTM) network of two layers
containing 256 units each. This LSTM network is a recurrent neural network
that saves information from the previous sample to be used by the current
sample. We chose the Shakespeare application because the clients have bigger
datasets with a small model to train.

The FEMNIST dataset creates a federated scenario to the extended MNIST
dataset, containing both handwritten letters and digits of size 28$\times$28\.
In this dataset, each client has the handwritten characters of a single user.
We selected users with more than 440 samples in total, which left us with 5
clients. After that, we replicated each client’s datasets to double their
number of samples. Thus, the training datasets of these five clients vary from
796 to 1050 samples and their test datasets vary from 90 to 118 samples. To
predict the character in an image in the FEMNIST dataset, we create a more
robust CNN than the reference one in LEAF [49] using 2 convolutional layers
followed by 10 fully connected layers with 4096 neurons each. We chose this
application because the clients have smaller datasets with a more robust model
to train compared to the Shakespeare application. Both applications allow us
to understand the behaviour of our Multi-FedLS with a wide range of different
characteristics (small vs. big dataset; simple vs. complex model).

All three applications used FedAvg as the server aggregation method.

###  5.2 Experimental setup

In our previous work [1, 14], experiments were carried out on two commercial
clouds: Amazon Web Services (AWS) and Google Cloud Provider (GCP). Both of
them restrict our GPU’s quotas, providing only 4 simultaneous GPUs. Thus, for
scalability sake, most experiments were conducted on CloudLab [15], a platform
that allows the simulation of cloud environments. It behaves similarly to a
real cloud platform, with predefined instances types in clusters in at least
three different US states555https://www.cloudlab.us/hardware.php. However,
contrary to real providers, CloudLab does not use virtualization but a bare
metal approach to isolate the instances requested by a user from others.
Moreover, CloudLab does not limit the number of vCPUs and GPUs per region
allocated by users. On the other hand, they use a reservation system, in which
users must specify which instances they want to use, and the latter will be
available during all the scheduled reservation. CloudLab has five different
clusters, with two of them in the same US state. We simulate two different
clouds by grouping the clusters into two clouds: Cloud A and Cloud B with
three and two clusters respectively. Each cluster simulates a different region
inside the respective cloud.

Table 2 summarizes the instance selection of the testbed. The VMs that have
GPUs are $vm_{126}$ with a P100 (12 GB of memory) and $vm_{138}$ with a Tesla
V100S (32 GB of memory). As CloudLab does not charge for the use of its
instances, we computed the on-demand price for each VM based on Google Cloud
Provider’s policy.

Table 2: Instance types selected Cloud | Cluster/Region | VM | vCPUS |  RAM (GB) |  | Costs per hour ($)
---
ID
On-demand | Spot
Cloud A | Utah | c6525-25g | 32 | 128 | 1.670 | 0.501 | $vm_{112}$
m510 | 16 | 64 | 0.835 | 0.250 | $vm_{114}$
xl170 | 20 | 64 | 0.971 | 0.291 | $vm_{115}$
Wisconsin | c220g1 | 32 | 128 | 1.670 | 0.501 | $vm_{121}$
c220g2 | 40 | 160 | 2.087 | 0.626 | $vm_{122}$
c240g1 | 32 | 128 | 1.670 | 0.501 | $vm_{124}$
c240g5 | 40 | 192 | 4.693 | 1.408 | $vm_{126}$
Clemson | dss7500 | 24 | 128 | 1.398 | 0.419 | $vm_{135}$
r7525 | 128 | 512 | 11.159 | 3.348 | $vm_{138}$
Cloud B | APT | c6220 | 32 | 64 | 1.283 | 0.385 | $vm_{211}$
r320 | 12 | 16 | 0.574 | 0.172 | $vm_{212}$
Massachusetts | rs440 | 64 | 192 | 2.837 | 0.851 | $vm_{221}$
rs630 | 40 | 256 | 2.349 | 0.705 | $vm_{222}$

We used the values of December 2022 of the computer-optimized instances of GCP
to Cloud A, $0.03398 per vCPU and $0.00455 per GB of RAM per hour, and
general-purpose instances to Cloud B, $0.031611 per vCPU and $0.004237 per GB
of RAM per hour. GPU’s architectures have different prices per hour being
$1.46 per P100, and $2.48 per V100. The spot price of a VM of a given type was
set by considering a 70% discount on the price of the on-demand VM of the same
type.

###  5.3 Pre-Scheduling slowdowns

We computed the computational slowdown for all instances in Table 2 using
$vm_{121}$ as the baseline VM. One client of the TIL use-case application
executed 38 training and 21 test samples. Table 3 shows the obtained
slowdowns. Note that all VMs have different execution times, varying the
slowdown from 0.045 and 2.328.

Table 3: Time of one client with five local epochs, dataset stored in Utah region of Cloud_A Cloud | Region | VM ID | Training time | Test time | Slowdown
---|---|---|---|---|---
1º r. | 2º r. | 1º r. | 2º r.
Cloud A | Utah | $vm_{112}$ | 123.12 | 120.93 | 1.61 | 1.47 | 1.064
$vm_{114}$ | 163.16 | 158.95 | 4.71 | 4.62 | 1.422
$vm_{115}$ | 113.22 | 110.32 | 2.95 | 2.86 | 0.984
Wisconsin | $vm_{121}$ | 119.89 | 112.83 | 2.30 | 2.22 | 1.000
$vm_{122}$ | 139.04 | 131.74 | 1.93 | 1.96 | 1.162
$vm_{124}$ | 119.05 | 110.45 | 2.23 | 2.12 | 0.970
$vm_{126}$ | 16.37 | 4.53 | 1.44 | 0.62 | 0.045
Clemson | $vm_{135}$ | 128.46 | 122.39 | 2.79 | 2.67 | 1.087
$vm_{138}$ | 71.67 | 60.14 | 5.39 | 5.24 | 0.568
Cloud B | APT | $vm_{211}$ | 147.79 | 141.62 | 4.22 | 4.26 | 1.268
$vm_{212}$ | 263.89 | 256.73 | 11.18 | 11.13 | 2.328
Massachusetts | $vm_{221}$ | 94.23 | 92.42 | 1.26 | 1.20 | 0.814
$vm_{222}$ | 112.44 | 103.59 | 1.91 | 1.75 | 0.916

We also computed the communication slowdowns in Table 4 using the pair of
regions Cloud_B_APT-Cloud_B_APT as the baseline. The training and test phases
exchange a total of 2GB in messages and a little more than 1GB respectively.
Note that communication times vary a lot in CloudLab, with the slowdown
ranging from 0.372 to 24.731.

Table 4: Time between each pair of regions Pair of regions | Comm. times (s) | Slowndown
---|---|---
Training | Test
Cloud_B_APT-Cloud_B_APT | 5.61 | 3.05 | 1.000
Cloud_B_APT-Cloud_A_Clemson | 12.05 | 5.94 | 2.078
Cloud_B_APT-Cloud_B_Mass | 106.90 | 54.51 | 18.641
Cloud_B_APT-Cloud_A_Utah | 4.84 | 2.58 | 0.857
Cloud_B_APT-Cloud_A_Wis | 16.19 | 7.64 | 2.752
Cloud_A_Clemson-Cloud_A_Clemson | 5.36 | 2.91 | 0.954
Cloud_A_Clemson-Cloud_B_Mass | 75.63 | 32.31 | 12.464
Cloud_A_Clemson-Cloud_A_Utah | 11.39 | 5.34 | 1.932
Cloud_A_Clemson-Cloud_A_Wis | 6.65 | 3.53 | 1.175
Cloud_B_Mass-Cloud_B_Mass | 5.23 | 2.81 | 0.929
Cloud_B_Mass-Cloud_A_Utah | 86.08 | 35.95 | 14.092
Cloud_B_Mass-Cloud_A_Wis | 138.31 | 75.85 | 24.731
Cloud_A_Utah-Cloud_A_Utah | 2.07 | 1.15 | 0.372
Cloud_A_Utah-Cloud_A_Wis | 21.81 | 10.57 | 3.738
Cloud_A_Wis-Cloud_A_Wis | 5.77 | 3.08 | 1.022

###  5.4 Validation of CloudLab environment

We validate the CloudLab environment using the most robust application, the
real-world TIL, in order to compare the obtained results with the ones of our
previous work of [1]. The baseline execution time (training and test phases)
for each client is 2765.4 seconds and the communication baseline is 8.66
seconds. TIL application executes for 10 communication rounds since such
number of rounds has presented the best ML metrics [44]. We assume the
transfer costs inside both clouds are the same as the ones evaluated for
Google Cloud Provider, $0.012 per sent GB.

The Initial Mapping module shows that the optimized configuration to run the
TIL application in CloudLab is composed of a VM $vm_{121}$ for the server and
four VMs $vm_{126}$ for clients. It also yields that the runtime would be
22:38 minutes and the costs would be $15.44. The average runtime value for
three executions is 24:47 minutes and the average cost is $16.18.

We observed that the model has a similar execution time and cost compared to
the real one for the TIL use-case application. The difference is 8.69% in the
execution time and 4.53% in costs, validating this new test environment with
the same setup used in [1].

However, we also noticed that our framework took longer to start the FL
execution in all VMs compared to real cloud providers. We compared the time to
execute the TIL application in CloudLab, in AWS, and in GCP, using the results
presented in [1]. The FL execution time in AWS corresponds to 91.45% of the
total Multi-FedLS execution time when there is no revocation. In CloudLab it
is only 31.67%, which can be explained by the bare-metal approach, which
increases the VM preparation time (2:34 in AWS versus 39:43 in CloudLab). The
same behavior is found when compared to GCP. There is a huge difference in the
preparation time (13:35 in GCP versus 39:43 in CloudLab). In GCP, the FL
execution time corresponds to 53.30% of the Multi-FedLS execution time.
Besides, one disadvantage of CloudLab is that once the instance is terminated,
the data modified in it gets lost, and we need to download the results before
terminating the VMs, which adds more than 20 minutes in the Multi-FedLS
execution. In AWS and GCP, we the produced data were stored in an extra volume
not deleted with the VM. It was thus possible to download them afterwards.

###  5.5 Checkpoint interval overhead

The next experiment evaluates the impact of the Fault Tolerance module on the
FL execution time and the total framework time using the TIL use-case
application because, among all applications, it has the biggest model and the
most costly checkpoint (504 MB). The number of rounds of the application was
increased aiming a longer execution time as well as the calling of the Fault
Tolerance and Dynamic Scheduler modules with different frequencies. We
distinguish two types of checkpoints: one on the server every $X$ rounds and
the client checkpoint every round. We evaluate them separately. Figure 2 shows
the average of Multi-FedLS and the FL execution time of three executions
varying the $X$ within 10, 20, 30, and 40 rounds.

Figure 2: Server checkpoint overhead.

We observe that the frequency of checkpointing impacts both execution times
similarly. The overhead compared to the FL execution without checkpoint varies
from 6.29% (30 rounds) to 7.55% (10 rounds). This overhead is mostly due to
the saving time to the local disk, as the checkpoints sending to another
location overlaps the server’s waiting for clients’ messages.

Since clients do not send their checkpoints to an external location, we
compute the clients’ checkpoint overhead saving the weights in the disk after
every evaluation step. The average execution time from three runs was 3:03:44
to the Multi-FedLS time and 2:06:20 when considering only the FL execution
time, which corresponds to a 2.17% overhead compared to no checkpoint
execution.

###  5.6 Failure simulation

Failure simulation experiments were conducted with the three applications in
order to observe the behaviour of Multi-FedLS as a whole at failure presence.

####  5.6.1 TIL application

To validate the Dynamic Scheduler module, we simulated the VM revocation using
a Poisson distribution [50] with a revocation rate $\lambda=1/k_{r}$, where
$k_{r}$ is the average time between failures in seconds. We observed patterns
in the revocation frequency in instances with GPU in AWS [47] which gave us
two different values to our experimental $k_{r}$, 2 hours and 4 hours. Thus,
there are two revocation rates: (i) $k_{r}=7200$ and $\lambda=1/7200$, and
(ii) $k_{r}=14400$ and $\lambda=1/14400$.

The revocation of a client and the server impact differently in the FL
execution. Thus, we considered two simulation scenarios to explore such a
difference. The first scenario (server and clients on spot VMs) uses
preemptible/spot VMs for all tasks. The second scenario (server on an on-
demand VM and clients on spot VMs) uses an on-demand VM to the server, which
increases the costs compared to the first scenario, but ensures the
reliability of the server task.

Table 5 shows the results for three executions for the two scenarios.

Table 5: Failure simulation using TIL application changing to another VM instance in CloudLab Scenario |  | Termination
---
rate
| Avg #
---
revoc.
| Avg exec.
---
time
| Avg total
---
costs
Server and clients on spot VMs | $k_{r}=7200$ | 3.67 | 10:01:46 | $81.12
$k_{r}=14400$ | 0.00 | 3:04:37 | $15.64
Server on an on-demand VM and clients on spot VMs | $k_{r}=7200$ | 1.00 | 6:31:44 | $55.60
$k_{r}=14400$ | 0.00 | 3:05:39 | $19.27

As a comparison, if all tasks execute on on-demand VMs without checkpoints,
the execution time is 2:59:39 and the total costs are $50.51.

Our dynamic scheduler always chooses the same instance types when there was a
revocation. Clients start on a VM $vm_{126}$ and restart on a VM $vm_{138}$.
The server starts on a VM $vm_{121}$ and restarts in a VM $vm_{212}$. There
was at most one revocation per task in each execution. In the first scenario,
two of the three executions had four revocations (3 clients and the server)
and the last one had three revocations (2 clients and the server), having an
average revocation number of 3.67. In the second scenario, one of the
executions had two revocations, another one revocation and the last one did
not have any revocation, resulting in one average revocation.

We can observe that spot VMs is not an advantage in CloudLab, since, given any
two VMs, client execution times are not similar. The $vm_{138}$ and $vm_{126}$
have slowdown of 0.568 and 0.045, respectively (Table 3). Moreover, the time
to instantiate the VMs also impacts the execution time, and, eventually, the
total costs with spot VMs surpass the costs when using only on-demand VMs.

Real commercial cloud providers usually have VMs with similar or even
equivalent configurations in different cloud regions. For example, AWS
provides g4dn.2xlarge instances (that have Turing GPUs) in 23 of its
regions666https://aws.amazon.com/ec2/pricing/on-demand/, accessed in May 2023
and GCP provides Turing GPUs in seven of its
regions777https://cloud.google.com/compute/docs/gpus/gpu-regions-zones,
acessed May 2023. These equivalent machines tend to have similar execution
times (with a slight difference), as observed in the slowdowns in our previous
paper [1]. On CloudLab, each instance type has completely different hardware
configurations, but it is possible to use the same instance type immediately
after a revocation. Our dynamic scheduler does not remove the VM that was
revoked from the available instance types (first line of Algorithm 3),
allowing, thus, the selection of the same instance type in every revocation.

Table 6 presents the results from three executions restarting in the same
instance type.

Table 6: Failure simulation using TIL application changing to the same VM instance in CloudLab Scenario |  | Termination
---
rate
| Avg #
---
revoc.
| Avg exec.
---
time
| Avg total
---
costs
Server and clients on spot VMs | $k_{r}=7200$ | 1.33 | 4:14:16 | $22.55
$k_{r}=14400$ | 0.00 | 3:04:35 | $15.64
Server on an on-demand VM and clients on spot VMs | $k_{r}=7200$ | 0.33 | 3:14:38 | $20.16
$k_{r}=14400$ | 0.00 | 3:01:49 | $18.99

In the first scenario with the termination rate of 1$/$(2 hours) ($1/7200$),
the first, second, and third executions had two clients, one client, and one
server revocations respectively, totaling an average of 1.33 revocations. In
the second scenario with the same termination rate, just one execution revoked
one client, having 0.33 as the average revocation number.

From these results, we can observe that the revocation of a client impacts
less the execution time than the server’s revocation (3:14:38 vs. 4:14:16).
Regarding the server execution in an on-demand VM vs. all tasks in spot VMs,
we can see that, when there is no revocation, costs increase by 21.30% ($18.99
vs. $15.64), otherwise they decrease by 10.58% ($20.16 vs. $22.55).

####  5.6.2 Benchmarks

The Shakespeare (resp., FEMINIST) applications were executed with 20 (resp.,
100) rounds and 20 (resp., 100) epochs per round, following the LEAF
configuration [49].

When executing both benchmarks, we observed that their execution times were
smaller than the one of the TIL application. Because of that, there was no
revocation with the first termination rate. Thus, we created a third
revocation rate, $k_{r}$ being 1 hour, i.e., (iii) $k_{r}=3600$ and
$\lambda=1/3600$.

Their execution using only on-demand VMs yields the following results. The
Shakespeare application executes for almost 1 hour and 54 minutes (1:53:54)
having a total cost of $53.31, while the FEMNIST application executes for 1
hour and 56 minutes (1:56:37) with a total cost of $35.68. The former costs
more than the latter because it has 8 clients and the FEMNIST one has only 5
clients, despite using the same VMs for server and clients.

Tables 7 and 8 show the results for the Shakespeare and FEMNIST applications
in CloudLab with the two previous scenarios under the two termination rates:
1$/$(1 hour) and 1$/$(2 hours). Both tables consider the average values for 3
executions.

Table 7: Failure simulation using Shakespeare changing to the same VM in CloudLab Scenario |  | Termination
---
rate
| Avg #
---
revoc.
| Avg exec.
---
time
| Avg total
---
costs
Server and clients on spot VMs | $k_{r}=3600$ | 1.33 | 2:17:12 | $20.02
$k_{r}=7200$ | 0.00 | 1:58:31 | $17.03
Server on an on-demand VM and clients on spot VMs | $k_{r}=3600$ | 2.67 | 2:32:12 | $23.46
$k_{r}=7200$ | 0.00 | 1:57:56 | $17.27
Table 8: Failure simulation using FEMNIST changing to the same VM in CloudLab Scenario |  | Termination
---
rate
| Avg #
---
revoc.
| Avg exec.
---
time
| Avg total
---
costs
Server and clients on spot VMs | $k_{r}=3600$ | 2.00 | 2:34:33 | $14.63
$k_{r}=7200$ | 0.00 | 1:52:21 | $10.21
Server on an on-demand VM and clients on spot VMs | $k_{r}=3600$ | 1.67 | 2:38:05 | $16.10
$k_{r}=7200$ | 0.00 | 1:56:02 | $11.35

The three executions of the Shakespeare application in the first scenario with
the first termination rate revoked only clients: two of them revoked only one
client and the last one revoked 2 clients, resulting in an average of 1.33
revocations. For FEMNIST, two executions revoked a client and the server (2
tasks in total each) and the last one revoked 2 clients, resulting in the
average of 2 revocations.

Similarly to the TIL application, we can observe that the use of spot
instances with these benchmarks is an advantage, especially to the clients
tasks. Regarding the server execution in an on-demand VM vs. all tasks in spot
VMs, costs increase on both applications, independently of having or not
revocations. In the Shakespeare application, we observe that the increase is
only by 1.39% when there is no revocation ($17.27 vs. $17.03) and by 17.16%
when there are revocations ($23.46 vs. $20.02). In the FEMNIST application,
both increases are similar, 11.12% without revocations ($11.15 vs. $10.21) and
10.10% with revocations ($16.10 and $ 14.63).

###  5.7 Execution in AWS/GCP

In this section, we present a proof-of-concept that our framework works in a
real-world multi-cloud scenario. The real-world application TIL was run on
both Amazon Web Services (AWS) and Google Cloud Provider (GCP), using three
regions in total: region us-east-1 (N. Virginia) in AWS and regions us-
central1 (Iowa) and us-west1 (Oregon) in GCP. The instances selected per
region are the same as in previous work [1], as shown in Table 9. The
g4dn.2xlarge instance has a Nvidia Tesla T4 Tensor Core GPU with 16 GB of
memory while the g3.4xlarge instance has a Nvidia Tesla M60 with 8 GB of
memory. In GCP, the Turing GPU is the same as the g4dn.2xlarge instance and
the Volta GPU is an Nvidia V100 Tensor Core, with 16 GB of memory.

Table 9: Instance types selected Cloud | Region | VM | vCPUS |  RAM (GB) |  | Costs per hour ($)
---
ID
On-demand | Spot
AWS |  N. Virginia (us-east-1) | g4dn.2xlarge | 8 | 32 | 0.752 | 0.318 | $vm_{311}$
g3.4xlarge | 16 | 122 | 1.140 | 0.638 | $vm_{312}$
t2.xlarge | 4 | 16 | 0.186 | 0.140 | $vm_{313}$
GCP |  Iowa (us-central1) |  n1-standard-8 with Turing GPU | 8 | 30 | 0.730 | 0.196 | $vm_{411}$
n1-standard-8 with Volta GPU | 8 | 30 | 2.860 | 0.857 | $vm_{413}$
e2-standard-4 | 4 | 16 | 0.134 | 0.040 | $vm_{414}$
Oregon (us-west1) |  n1-standard-8 with Volta GPU | 8 | 30 | 2.860 | 0.857 | $vm_{422}$
e2-standard-4 | 4 | 16 | 0.134 | 0.040 | $vm_{423}$

In this experiment, due to GPU and vCPU restrictions, we only considered 2
clients whose dataset is stored in AWS and the GCP respectively. Our Initial
Mapping module computed the optimal setup as all tasks running in AWS, with
the server in VM $vm_{313}$ and the clients in VMs $vm_{311}$. The average
values of three executions in only on-demand VMs yielded a runtime of 2:00:18
and a cost of $3.28. When FL was executed with all tasks in Spot VMs and
failures were simulated with a termination rate of 2 hours ($k_{r}=7200$), we
obtained an average number of revocations of 1.33, i.e., 1 server revocation
in each run and 1 client revocation in one run. The average execution time of
these runs was 2:06:51 and the costs are $1.41.

##  6 Conclusions and Future Work

We presented in this article the Multi-FedLS, a multi-cloud framework for
Cross-Silo FL applications, which aims at reducing execution time and
financial costs of such applications. Multi-FedLS can be composed of both on-
demand and preemptible VMs, providing a checkpoint mechanism and a dynamic
scheduler that manage the replacement of preemptible VMs, in case of
revocation. We validated Multi-FedLS in CloudLab [15], a platform that
simulates cloud environments, with one real-world application and two FL
benchmarks from LEAF [49]. We also presented a proof of concept by executing
the real-world application on a multi-cloud platform with two real cloud
providers, Amazon Web Services and Google Cloud Provider. Our framework
obtained a reduction cost of 56.92% when compared to the execution of only on-
demand VMs with an execution time increase of only 5.44% in commercial clouds.

Future research directions include the extension of Multi-FedLS for executing
several FL applications simultaneously as well as the study of the impact of
other models used in FL application, such as linear regression or Support
Machine Vectors (SVMs).

## References

  * [1] R. C. Brum, P. Sens, L. Arantes, M. C. Castro, L. M. de A. Drummond, Optimizing execution time and costs of cross-silo federated learning applications with datasets on different cloud providers, in: 2022 IEEE 34th International Symposium on Computer Architecture and High Performance Computing (SBAC-PAD), 2022, pp. 253–262.  doi:10.1109/SBAC-PAD55451.2022.00036.
  * [2] B. McMahan, E. Moore, D. Ramage, S. Hampson, B. A. y Arcas, Communication-Efficient Learning of Deep Networks from Decentralized Data, in: A. Singh, J. Zhu (Eds.), Proceedings of the 20th International Conference on Artificial Intelligence and Statistics, Vol. 54 of Proceedings of Machine Learning Research, PMLR, Fort Lauderdale, FL, USA, 2017, pp. 1273–1282.
  * [3] S. Shen, T. Zhu, D. Wu, W. Wang, W. Zhou, From distributed machine learning to federated learning: In the view of data privacy and security, Concurrency and Computation: Practice and Experience (2020).  doi:https://doi.org/10.1002/cpe.6002.
  * [4] Q. Yang, Y. Liu, T. Chen, Y. Tong, Federated Machine Learning: Concept and Applications, ACM Trans. Intell. Syst. Technol. 10 (2) (Jan. 2019).  doi:10.1145/3298981.
  * [5] V.-D. Nguyen, S. K. Sharma, T. X. Vu, S. Chatzinotas, B. Ottersten, Efficient federated learning algorithm for resource allocation in wireless iot networks, IEEE Internet of Things Journal 8 (5) (2021) 3394–3409.  doi:10.1109/JIOT.2020.3022534.
  * [6] M. Mohammadi Amiri, D. Gündüz, Computation scheduling for distributed machine learning with straggling workers, IEEE Transactions on Signal Processing 67 (24) (2019) 6270–6284.  doi:10.1109/TSP.2019.2952051.
  * [7] L. Liu, H. Yu, G. Sun, H. Zhou, Z. Li, S. Luo, Online job scheduling for distributed machine learning in optical circuit switch networks, Knowledge-Based Systems 201-202 (2020) 106002.  doi:https://doi.org/10.1016/j.knosys.2020.106002.
  * [8] M. Yu, J. Liu, C. Wu, B. Ji, E. Bentley, Toward efficient online scheduling for distributed machine learning systems, IEEE Transactions on Network Science and Engineering (2021) 1–1doi:10.1109/TNSE.2021.3104513.
  * [9] A. Li, X. Yang, S. Kandula, M. Zhang, CloudCmp: Comparing Public Cloud Providers, in: Proceedings of the 10th ACM SIGCOMM Conference on Internet Measurement, IMC ’10, Association for Computing Machinery, New York, NY, USA, 2010, p. 1–14.  doi:10.1145/1879141.1879143.
  * [10] H. Liu, Big data drives cloud adoption in enterprise, IEEE Internet Computing 17 (4) (2013) 68–71.  doi:10.1109/MIC.2013.63.
  * [11] N. Leavitt, Storage challenge: Where will all that big data go?, Computer 46 (09) (2013) 22–25.
  * [12] S. Ostermann, A. Iosup, N. Yigitbasi, R. Prodan, T. Fahringer, D. Epema, A Performance Analysis of EC2 Cloud Computing Services for Scientific Computing, in: Cloud Computing, Springer Berlin Heidelberg, Berlin, Heidelberg, 2010, pp. 115–131.
  * [13] C. Kotas, T. Naughton, N. Imam, A comparison of Amazon Web Services and Microsoft Azure cloud platforms for high performance computing, in: 2018 IEEE Inter. Conf. on Consumer Electronics (ICCE), 2018, pp. 1–4.  doi:10.1109/ICCE.2018.8326349.
  * [14] R. C. Brum, P. Sens, L. Arantes, M. C. Castro, L. M. d. A. Drummond, Towards a federated learning framework on a multi-cloud environment, in: 2022 International Symposium on Computer Architecture and High Performance Computing Workshops (SBAC-PADW), 2022, pp. 39–44.  doi:10.1109/SBAC-PADW56527.2022.00016.
  * [15] D. Duplyakin, et al., The design and operation of CloudLab, in: Proceedings of the USENIX Annual Technical Conference (ATC), 2019, pp. 1–14.
  * [16] H. H. Yang, Z. Liu, T. Q. S. Quek, H. V. Poor, Scheduling policies for federated learning in wireless networks, IEEE Transactions on Communications 68 (1) (2020) 317–333.  doi:10.1109/TCOMM.2019.2944169.
  * [17] B. Buyukates, S. Ulukus, Timely communication in federated learning, in: IEEE INFOCOM 2021 - IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), 2021, pp. 1–6.  doi:10.1109/INFOCOMWKSHPS51825.2021.9484497.
  * [18] L. Lima Pilla, Optimal task assignment for heterogeneous federated learning devices, in: 2021 IEEE International Parallel and Distributed Processing Symposium (IPDPS), 2021, pp. 661–670.  doi:10.1109/IPDPS49936.2021.00074.
  * [19] T. Li, A. K. Sahu, M. Zaheer, M. Sanjabi, A. Talwalkar, V. Smith, Federated optimization in heterogeneous networks, arXiv preprint arXiv:1812.06127 (2018).
  * [20] A. M. Abdelmoniem, C.-Y. Ho, P. Papageorgiou, M. Canini, A comprehensive empirical study of heterogeneity in federated learning, IEEE Internet of Things Journal (2023) 1–1doi:10.1109/JIOT.2023.3250275.
  * [21] S. Rajendran, et al., Cloud-Based Federated Learning Implementation Across Medical Centers, JCO Clinical Cancer Informatics 5 (2021) 1–11.  doi:10.1200/CCI.20.00060.
  * [22] Y. Huang, L. Chu, Z. Zhou, L. Wang, J. Liu, J. Pei, Y. Zhang, Personalized Cross-Silo Federated Learning on Non-IID Data, Proceedings of the AAAI Conference on Artificial Intelligence 35 (9) (2021) 7865–7873.
  * [23] Q. Li, Y. Diao, Q. Chen, B. He, Federated learning on non-iid data silos: An experimental study, ArXiv abs/2102.02079 (2021).
  * [24] S. Shastri, D. Irwin, Cloud index tracking: Enabling predictable costs in cloud spot markets, in: Proceedings of the ACM Symposium on Cloud Computing, SoCC ’18, Association for Computing Machinery, New York, NY, USA, 2018, p. 451–463.  doi:10.1145/3267809.3267821.
  * [25] P. Varshney, Y. Simmhan, Autobot: Resilient and cost-effective scheduling of a bag of tasks on spot vms, IEEE Transactions on Parallel and Distributed Systems 30 (7) (2019) 1512–1527.  doi:10.1109/TPDS.2018.2889851.
  * [26] J. Fabra, J. Ezpeleta, P. Álvarez, Reducing the price of resource provisioning using ec2 spot instances with prediction models, Future Generation Computer Systems 96 (2019) 348–367.  doi:https://doi.org/10.1016/j.future.2019.01.025.
  * [27] A. Chhabra, K.-C. Huang, N. Bacanin, T. A. Rashid, Optimizing bag-of-tasks scheduling on cloud data centers using hybrid swarm-intelligence meta-heuristic, The Journal of Supercomputing 78 (7) (2022) 9121–9183.  doi:10.1007/s11227-021-04199-0.
URL https://doi.org/10.1007/s11227-021-04199-0

  * [28] L. Yin, J. Zhou, J. Sun, A stochastic algorithm for scheduling bag-of-tasks applications on hybrid clouds under task duration variations, Journal of Systems and Software 184 (2022) 111123.  doi:https://doi.org/10.1016/j.jss.2021.111123.
  * [29] A. C. Zhou, J. Lao, Z. Ke, Y. Wang, R. Mao, Farspot: Optimizing monetary cost for hpc applications in the cloud spot market, IEEE Transactions on Parallel and Distributed Systems 33 (11) (2022) 2955–2967.  doi:10.1109/TPDS.2021.3134644.
  * [30] L. Teylo, L. Arantes, P. Sens, L. M. d. A. Drummond, Scheduling bag-of-tasks in clouds using spot and burstable virtual machines, IEEE Transactions on Cloud Computing 11 (1) (2023) 984–996.  doi:10.1109/TCC.2021.3125426.
  * [31] M. Karaja, A. Chaabani, A. Azzouz, L. Ben Said, Efficient bi-level multi objective approach for budget-constrained dynamic bag-of-tasks scheduling problem in heterogeneous multi-cloud environment, Applied Intelligence 53 (8) (2023) 9009–9037.  doi:10.1007/s10489-022-03942-1.
URL https://doi.org/10.1007/s10489-022-03942-1

  * [32] L. Brotcorne, J. Ezpeleta, C. Galé, A biobjective model for resource provisioning in multi-cloud environments with capacity constraints, Operational Research 23 (2) (2023) 31.  doi:10.1007/s12351-023-00773-x.
URL https://doi.org/10.1007/s12351-023-00773-x

  * [33] N. Truong, K. Sun, S. Wang, F. Guitton, Y. Guo, Privacy preservation in federated learning: An insightful survey from the gdpr perspective, Computers & Security 110 (2021) 102402.  doi:https://doi.org/10.1016/j.cose.2021.102402.
  * [34] L. Liu, J. Zhang, S. Song, K. B. Letaief, Client-edge-cloud hierarchical federated learning, in: 2020-2020 IEEE International Conference on Communications, 2020.
  * [35] C. Fang, Y. Guo, N. Wang, A. Ju, Highly efficient federated learning with strong privacy preservation in cloud computing, Computers & Security 96 (2020) 101889.  doi:https://doi.org/10.1016/j.cose.2020.101889.
  * [36] M. Docs, What is Azure Databricks?, https://docs.microsoft.com/en-us/azure/databricks/scenarios/what-is-azure-databricks, accessed 16 January 2022 (2022).
  * [37] X.-P. Zhao, R. Jiang, Distributed machine learning oriented data integrity verification scheme in cloud computing environment, IEEE Access 8 (2020) 26372–26384.  doi:10.1109/ACCESS.2020.2971519.
  * [38] X. Zhang, J. Wang, G. Joshi, C. Joe-Wong, Machine learning on volatile instances, in: IEEE INFOCOM 2020 - IEEE Conference on Computer Communications, 2020, pp. 139–148.  doi:10.1109/INFOCOM41043.2020.9155448.
  * [39] T. N. B. Duong, N. Q. Sang, Distributed Machine Learning on IAAS Clouds, in: 2018 5th IEEE International Conference on Cloud Computing and Intelligence Systems (CCIS), 2018, pp. 58–62.  doi:10.1109/CCIS.2018.8691150.
  * [40] T. N. B. Duong, $FC^{2}$: cloud-based cluster provisioning for distributed machine learning, Cluster Computing 22 (4) (2019) 1299–1315.  doi:10.1007/s10586-019-02912-6.
URL https://doi.org/10.1007/s10586-019-02912-6

  * [41] M. Wagenländer, L. Mai, G. Li, P. Pietzuch, Spotnik: Designing Distributed Machine Learning for Transient Cloud Resources, in: 12th USENIX Workshop on Hot Topics in Cloud Computing (HotCloud 20), USENIX Association, 2020.
  * [42] D. J. Beutel, T. Topal, A. Mathur, X. Qiu, T. Parcollet, N. Lane, Flower: A friendly federated learning research framework, ArXiv abs/2007.14390 (2020).
  * [43] R. Brum, L. Drummond, M. C. Castro, G. Teodoro, Towards optimizing computational costs of federated learning in clouds, in: 2021 International Symposium on Computer Architecture and High Performance Computing Workshops (SBAC-PADW), 2021, pp. 35–40.  doi:10.1109/SBAC-PADW53941.2021.00016.
  * [44] R. Brum, G. Teodoro, L. Drummond, L. Arantes, M. Castro, P. Sens, Evaluating federated learning scenarios in a tumor classification application, in: Anais da VII Escola Regional de Alto Desempenho do Rio de Janeiro, SBC, Porto Alegre, RS, Brasil, 2021, pp. 6–10.  doi:10.5753/eradrj.2021.18558.
  * [45] R. C. Brum, L. Arantes, M. C. Castro, P. Sens, L. M. A. Drummond, Evaluating Execution Times and Costs of a Federated Learning Application on different Cloud Providers, in: COMPAS 2022 - Conférence francophone d’informatique en Parallélisme, Architecture et Système, Amiens, France, 2022.
  * [46] J. D. Ullman, Np-complete scheduling problems, Journal of Computer and System sciences 10 (3) (1975) 384–393.
  * [47] R. C. Brum, W. P. Sousa, A. C. M. A. Melo, C. Bentes, M. C. S. de Castro, L. M. d. A. Drummond, A Fault Tolerant and Deadline Constrained Sequence Alignment Application on Cloud-Based Spot GPU Instances, in: Euro-Par 2021: Parallel Processing, Springer International Publishing, Cham, 2021, pp. 317–333.
  * [48] J. Saltz, et al., Spatial Organization And Molecular Correlation Of Tumor-Infiltrating Lymphocytes Using Deep Learning On Pathology Images, Cell reports 23 (1) (2018) 181.
  * [49] S. Caldas, S. M. K. Duddu, P. Wu, T. Li, J. Konečný, H. B. McMahan, V. Smith, A. Talwalkar, Leaf: A benchmark for federated settings (2019).  arXiv:1812.01097.
  * [50] J. H. Ahrens, U. Dieter, Computer methods for sampling from gamma, beta, poisson and bionomial distributions, Computing 12 (3) (1974) 223–246.


complex is still acyclic; unravel the totalization and use the formula

$W_{e}=(\widetilde{{\mathbf{D}}}^{[r,+\infty)}\otimes_{{\widetilde{{\mathbf{B}}}}^{[r,+\infty)}}{\widetilde{{\mathbf{B}}}_{\mathrm{rig}}^{\dagger}}[1/t])^{{\varphi}=1},$

we obtain the desired quasi-isomorphism (9.6). ∎

###  9.4. ${\varphi}$-equivariant Lie algebra cohomologies

We finally treat the complex
$C_{\varphi,N_{\nabla}}({\mathbf{D}}_{{\mathrm{rig}},{K_{\infty}}}^{\dagger})$.

######  Lemma 9.12.

$C_{\varphi,N_{\nabla}}({\mathbf{D}}_{{\mathrm{rig}},{K_{\infty}}}^{\dagger})$
is quasi-isomorphic to the complex

${\mathbf{D}}_{{K_{\infty}}}^{[r,pr]}\xrightarrow{{\varphi}-1,N_{\nabla}}{\mathbf{D}}_{{K_{\infty}}}^{[pr,pr]}\oplus{\mathbf{D}}_{{K_{\infty}}}^{[r,pr]}\xrightarrow{N_{\nabla},\frac{pE(u)}{E(0)}{\varphi}-1}{\mathbf{D}}_{{K_{\infty}}}^{[pr,pr]}$

###### Proof.

By Rem. 9.3,
$C_{\varphi,N_{\nabla}}({\mathbf{D}}_{{\mathrm{rig}},{K_{\infty}}}^{\dagger})$
is quasi-isomorphic to the totalization of

${{{\mathbf{D}}_{{\mathrm{rig}},{K_{\infty}}}^{\dagger}}}$${{{\mathbf{D}}_{{\mathrm{rig}},{K_{\infty}}}^{\dagger}}}$${{{\mathfrak{t}}{\mathbf{D}}_{{\mathrm{rig}},{K_{\infty}}}^{\dagger}}}$${{{\mathfrak{t}}{\mathbf{D}}_{{\mathrm{rig}},{K_{\infty}}}^{\dagger}}}$$\scriptstyle{\nabla_{\tau}}$$\scriptstyle{{\varphi}-1}$$\scriptstyle{\nabla_{\tau}}$$\scriptstyle{{\varphi}-1}$

Note in above diagram, since we are working ${\mathbb{Q}_{p}}$-rationally,
using ${\mathfrak{t}}$ is equivalent to using $p{\mathfrak{t}}$ or
$p^{2}{\mathfrak{t}}$. The top row is quasi-isomorphic to
$C_{\varphi}({\mathbf{D}}_{{K_{\infty}}}^{[r,pr]})$ by Lem. 8.4. It remains to
prove

$C_{\varphi}({\mathfrak{t}}{\mathbf{D}}_{{\mathrm{rig}},{K_{\infty}}}^{\dagger})\simeq
C_{\varphi}({\mathfrak{t}}{\mathbf{D}}_{{K_{\infty}}}^{[r,pr]})$

The point is that [KL, Prop. 5.4.12] (as applied in our Lem. 8.4) is still
applicable here, because
${\mathfrak{t}}{\mathbf{D}}_{{\mathrm{rig}},{K_{\infty}}}^{\dagger}$ is still
a ${\varphi}$-module over
$\mathbf{B}_{{\mathrm{rig}},{K_{\infty}}}^{\dagger}$! Indeed,
${\varphi}({\mathfrak{t}})=\frac{pE(u)}{E(0)}{\mathfrak{t}}$ and
$\frac{pE(u)}{E(0)}$ is a unit in
$\mathbf{B}_{{\mathrm{rig}},{K_{\infty}}}^{\dagger}$. ∎

######  Theorem 9.13.

Let ${\mathbb{D}}_{{\mathrm{rig}},{K_{p^{\infty}}}}^{\dagger}$ be a
$({\varphi},\Gamma)$-module, and use Notation 3.9. Let $W$ be the associated
$B$-pair.

  1. (1)

We have a quasi-isomorphism

$C_{{\varphi},\nabla_{\gamma}}({\mathbb{D}}_{{\mathrm{rig}},{K_{p^{\infty}}}}^{\dagger})\simeq\varinjlim_{n}\mathrm{R}\Gamma(G_{K(\mu_{n})},W)$

Taking cohomology, we obtain

(9.7)
$H^{i}_{{\varphi},\nabla_{\gamma}}({\mathbb{D}}_{{\mathrm{rig}},{K_{p^{\infty}}}}^{\dagger})\simeq\varinjlim_{n}H^{i}(G_{K(\mu_{n})},W)=\bigcup_{n}H^{i}(G_{K(\mu_{n})},W)$

  2. (2)

We have a quasi-isomorphism

$C_{{\varphi},{N_{\nabla}}}({\mathbf{D}}_{{\mathrm{rig}},{K_{\infty}}}^{\dagger})\simeq\varinjlim_{n}\mathrm{R}\Gamma(G_{K(\pi_{n})},W)$

Taking cohomology, we obtain

(9.8)
$H^{i}_{{\varphi},N_{\nabla}}({\mathbf{D}}_{{\mathrm{rig}},{K_{\infty}}}^{\dagger})\simeq\varinjlim_{n}H^{i}(G_{K(\pi_{n})},W)=\bigcup_{n}H^{i}(G_{K(\pi_{n})},W)$

###### Proof.

Consider Item (1). We have

$\displaystyle\
C_{{\varphi},\nabla_{\gamma}}({\mathbb{D}}_{{\mathrm{rig}},{K_{p^{\infty}}}}^{\dagger})\quad$
$\displaystyle\simeq$ $\displaystyle
C_{{\varphi},\nabla_{\gamma}}({\mathbb{D}}_{{K_{p^{\infty}}}}^{[r,pr]})\quad$
by Lem. 8.4 and Convention 9.4 $\displaystyle\simeq$ $\displaystyle
C_{\varphi}(\mathrm{R}\Gamma(\mathrm{Lie}{\Gamma_{K}},{\mathbb{D}}_{{K_{p^{\infty}}}}^{[r,pr]})),\quad$
re-writing above $\displaystyle\simeq$ $\displaystyle
C_{\varphi}(\varinjlim_{n}\mathrm{R}\Gamma_{\mathrm{la}}({\mathrm{Gal}}({K_{p^{\infty}}}/K(\mu_{n}),{\mathbb{D}}_{{K_{p^{\infty}}}}^{[r,pr]}))\quad$
by Thm. 2.13 $\displaystyle\simeq$ $\displaystyle
C_{\varphi}(\varinjlim_{n}\mathrm{R}\Gamma_{\mathrm{cont}}({\mathrm{Gal}}({K_{p^{\infty}}}/K(\mu_{n}),{\mathbb{D}}_{{K_{p^{\infty}}}}^{[r,pr]}))\quad$
by Thm. 2.13 $\displaystyle\simeq$
$\displaystyle\varinjlim_{n}C_{\varphi}(\mathrm{R}\Gamma_{\mathrm{cont}}({\mathrm{Gal}}({K_{p^{\infty}}}/K(\mu_{n}),{\mathbb{D}}_{{K_{p^{\infty}}}}^{[r,pr]}))\quad$
cohomology commutes with colimits $\displaystyle\simeq$
$\displaystyle\varinjlim_{n}C_{{\varphi},\Gamma_{K(\mu_{n})}}({\mathbb{D}}_{{\mathrm{rig}},{K_{p^{\infty}}}}^{\dagger}),\quad$
by Lem. 8.4 $\displaystyle\simeq$
$\displaystyle\varinjlim_{n}\mathrm{R}\Gamma(G_{K(\mu_{n})},W),\quad$ by Thm.
9.11

Taking cohomology, we obtain (9.7): indeed, the inductive limit of
cohomologies of $B$ pairs above is an increasing union because

(9.9)
$\mathrm{R}\Gamma(G_{K(\mu_{n})},W)\simeq\mathrm{R}\Gamma({\mathrm{Gal}}(K(\mu_{n+1})/K(\mu_{n})),\mathrm{R}\Gamma(G_{K(\mu_{n+1})},W)$

and finite group cohomology on ${\mathbb{Q}_{p}}$-vector spaces is
concentrated in degree zero (cf. e.g. [HS97, Cor. 16.5]).

Consider Item (2). We have

$\displaystyle\
C_{{\varphi},{N_{\nabla}}}({\mathbf{D}}_{{\mathrm{rig}},{K_{\infty}}}^{\dagger})\quad$
$\displaystyle\simeq$ $\displaystyle
C_{{\varphi},{N_{\nabla}}}({\mathbf{D}}_{{K_{\infty}}}^{[r,pr]})\quad$ by Lem.
8.4 $\displaystyle\simeq$ $\displaystyle
C_{{\varphi},{N_{\nabla}}}({\mathbf{D}}_{{K_{\infty}},\infty}^{[r,pr]})\quad$
by Lem. 8.1 $\displaystyle\simeq$ $\displaystyle
C_{\varphi}((\mathrm{R}\Gamma(\mathrm{Lie}{\hat{G}},\widetilde{\mathbf{D}}_{L}^{[r,pr],{\mathrm{la}}})^{{\mathrm{Gal}}(L/{K_{\infty}})=1}),\quad$
by Cor. 7.6

For notation simplicity, we first compute above cohomology without taking
${\mathrm{Gal}}(L/{K_{\infty}})=1$. Very similar to computations in Item (1),
we have

$\displaystyle\
C_{\varphi}(\mathrm{R}\Gamma(\mathrm{Lie}{\hat{G}},\widetilde{\mathbf{D}}_{L}^{[r,pr],{\mathrm{la}}}))\quad$
$\displaystyle\simeq$ $\displaystyle
C_{\varphi}(\varinjlim_{n}\mathrm{R}\Gamma_{\mathrm{la}}({\mathrm{Gal}}(L/K(\pi_{n},\mu_{n}),\widetilde{{\mathbf{D}}}_{L}^{[r,pr],{\mathrm{la}}}))\quad$
by Thm. 2.13 $\displaystyle\simeq$ $\displaystyle
C_{\varphi}(\varinjlim_{n}\mathrm{R}\Gamma_{\mathrm{cont}}({\mathrm{Gal}}(L/K(\pi_{n},\mu_{n}),\widetilde{{\mathbf{D}}}_{L}^{[r,pr]}))\quad$
by Thm. 2.13 $\displaystyle\simeq$
$\displaystyle\varinjlim_{n}C_{{\varphi},{\mathrm{Gal}}(L/K(\pi_{n},\mu_{n}))}(\widetilde{{\mathbf{D}}}_{{\mathrm{rig}},L}^{\dagger}),\quad$
by Lem. 8.4 $\displaystyle\simeq$
$\displaystyle\varinjlim_{n}\mathrm{R}\Gamma(G_{K(\pi_{n},\mu_{n})},W),\quad$
by Thms. 9.9 and 9.11

We can conclude by taking ${\mathrm{Gal}}(L/{K_{\infty}})$-invariants. (Note
here, the ${\mathrm{Gal}}(L/{K_{\infty}})$-action on
$\mathrm{R}\Gamma(G_{K(\pi_{n},\mu_{n})},W)$ factors through a finite
quotient.) ∎

######  Remark 9.14.

  1. (1)

Item (1) of Thm. 9.13 is strictly stronger than the comparison in Item (3) of
Thm. 9.9; since the later follows by taking ${\Gamma_{K}}$-invariant of the
former.

  2. (2)

From the comparison

$H^{i}_{{\varphi},N_{\nabla}}({\mathbf{D}}_{{\mathrm{rig}},{K_{\infty}}}^{\dagger})\simeq\bigcup_{n}H^{i}(G_{K(\pi_{n})},W)$

One can define

$(H^{i}_{{\varphi},N_{\nabla}}({\mathbf{D}}_{{\mathrm{rig}},{K_{\infty}}}^{\dagger}))^{\tau=1}:=H^{i}_{{\varphi},N_{\nabla}}({\mathbf{D}}_{{\mathrm{rig}},{K_{\infty}}}^{\dagger})\cap(\bigcup_{n}H^{i}(G_{K(\mu_{n},\pi_{n})},W))^{\tau=1}$

And then obviously

$(H^{i}_{{\varphi},N_{\nabla}}({\mathbf{D}}_{{\mathrm{rig}},{K_{\infty}}}^{\dagger}))^{\tau=1}\simeq
H^{i}({G_{K}},W)$

We do not expect this very _artificial_ construction to be very useful.

###  9.5. Some “wrong” $(\varphi,\tau)$-complexes

This subsection is a continuation of §8.2. Recall there we studied some
“natural” $\varphi$-complexes that turn out to be “wrong” ones; we now show
they induce some “natural” $(\varphi,\tau)$-complexes that also turn out to be
“wrong” complexes (as mentioned in the statements of Thms. 9.5 and 9.9). Let
$K/{\mathbb{Q}_{p}}$ be a finite extension, and consider
$V\in{\mathrm{Rep}}_{\mathbb{Q}_{p}}({G_{K}})$. Use Notations 3.8 and 3.9.

######  Proposition 9.15.

We have a quasi-isomorphism

(9.10)
$C_{{\varphi},\tau}({\mathbf{D}}_{{K_{\infty}}}^{\dagger},\widetilde{\mathbf{D}}_{L}^{\dagger})\simeq
C_{{\varphi},\tau}({\mathbf{D}}_{{\mathrm{rig}},{K_{\infty}}}^{\dagger},\widetilde{\mathbf{D}}_{{\mathrm{rig}},L}^{\dagger});$

but they are (in general) _not_ quasi-isomorphic to
$C_{{\varphi},\tau}(\widetilde{\mathbf{D}}_{{\mathrm{rig}},{K_{\infty}}}^{\dagger},\widetilde{\mathbf{D}}_{{\mathrm{rig}},L}^{\dagger})$
(equivalently, to $\mathrm{R}\Gamma({G_{K}},V)$): this is already so when
$V={\mathbb{Q}_{p}}$ is the trivial representation. (Thus, both complexes in
Eqn. (9.10) are _wrong_ ones.)

###### Proof.

Note $C_{\varphi,\tau}(M,{\widetilde{M}})$ is the totalization of the double
complex

(9.11)
${M}$${{\widetilde{M}}^{\delta-\gamma=0}}$${M}$${{\widetilde{M}}^{\delta-\gamma=0}}$$\scriptstyle{\varphi-1}$$\scriptstyle{\tau-1}$$\scriptstyle{\varphi-1}$$\scriptstyle{\tau-1}$

Thus to prove

$C_{{\varphi},\tau}({\mathbf{D}}_{{K_{\infty}}}^{\dagger},\widetilde{\mathbf{D}}_{L}^{\dagger})\simeq
C_{{\varphi},\tau}({\mathbf{D}}_{{\mathrm{rig}},{K_{\infty}}}^{\dagger},\widetilde{\mathbf{D}}_{{\mathrm{rig}},L}^{\dagger})$

it suffices to prove

$C_{\varphi}({\mathbf{D}}_{{K_{\infty}}}^{\dagger})\simeq
C_{\varphi}({\mathbf{D}}_{{\mathrm{rig}},{K_{\infty}}}^{\dagger})\text{ and
}C_{\varphi}(\widetilde{\mathbf{D}}_{L}^{\dagger})\simeq
C_{\varphi}(\widetilde{\mathbf{D}}_{{\mathrm{rig}},L}^{\dagger})$

these follow from [Ked08, Prop. 1.5.4].

We now prove
$C_{{\varphi},\tau}({\mathbf{D}}_{{K_{\infty}}}^{\dagger},\widetilde{\mathbf{D}}_{L}^{\dagger})$
is _not_ quasi-isomorphic to
$C_{{\varphi},\tau}(\widetilde{\mathbf{D}}_{{\mathrm{rig}},{K_{\infty}}}^{\dagger},\widetilde{\mathbf{D}}_{{\mathrm{rig}},L}^{\dagger})$.
Staring at their associated double complexes (9.11), it suffices to note that
$C_{\varphi}({\mathbf{D}}_{K_{\infty}}^{\dagger})$ and
$C_{\varphi}(\widetilde{{\mathbf{D}}}_{K_{\infty}}^{\dagger})$ are _not_
quasi-isomorphic, by Prop. 8.7.

∎

###  9.6. Final remarks

In this subsection, we make some extensive historical comparisons on the study
of cohomology of $(\varphi,\Gamma)$-modules; most interestingly, we comment
how we avoided using $\psi$-operator in the current paper (which leads to
slightly stronger new results). Nonetheless, in the future, we very much hope
to gain some understanding of the very mysterious (indeed, very baffling)
$\psi$-operator for the $(\varphi,\tau)$-modules.

######  Remark 9.16.

We discuss the (rather involved) history of Herr complexes of (various)
$(\varphi,\Gamma)$-modules when they are associated to Galois representations.
For simplicity, we only discuss results concerning
$V\in{\mathrm{Rep}}_{G_{K}}({\mathbb{Q}_{p}})$.

  1. (1)

In [Her98], Herr proves that

$C_{\varphi,{\Gamma_{K}}}({\mathbb{D}}_{K_{p^{\infty}}})\simeq\mathrm{R}\Gamma({G_{K}},V)$

His results indeed hold for $V$ a torsion representation or integral
${\mathbb{Z}_{p}}$-representation; in fact, his proof goes via devissage to
the torsion case, where he proves the construction of the complex
$C_{\varphi,{\Gamma_{K}}}({\mathbb{D}}_{K_{p^{\infty}}})$ is a
$\delta$-functor.

  2. (2)

The complexes
$C_{\varphi,{\Gamma_{K}}}({\mathbb{D}}_{K_{p^{\infty}}}^{\dagger})$ and
$C_{\varphi,{\Gamma_{K}}}({\mathbb{D}}_{{\mathrm{rig}},{K_{p^{\infty}}}}^{\dagger})$
are _much_ trickier. In [Liu08a], under the assumption $K/{\mathbb{Q}_{p}}$ is
a _finite extension_ , Liu proves their comparison with
$\mathrm{R}\Gamma({G_{K}},V)$. His argument goes in the following route
(slightly modified and simplified here):

     * •

Liu first deals with
$C_{\varphi,{\Gamma_{K}}}({\mathbb{D}}_{K_{p^{\infty}}}^{\dagger})$. One has
comparison

$C_{\varphi,{\Gamma_{K}}}({\mathbb{D}}_{K_{p^{\infty}}}^{\dagger})\simeq
C_{\psi,{\Gamma_{K}}}({\mathbb{D}}_{K_{p^{\infty}}}^{\dagger});\quad
C_{\varphi,{\Gamma_{K}}}({\mathbb{D}}_{K_{p^{\infty}}})\simeq
C_{\psi,{\Gamma_{K}}}({\mathbb{D}}_{K_{p^{\infty}}});$

these are proved by [CC98]; cf. also [Liu08a, Lem. 2.5] for a review and
summary. Liu then proves

$C_{\psi}({\mathbb{D}}_{K_{p^{\infty}}}^{\dagger})\simeq
C_{\psi}({\mathbb{D}}_{K_{p^{\infty}}})$

cf. [Liu08a, Lem. 2.6], which makes essential use that $K/{\mathbb{Q}_{p}}$ is
a finite extension. This implies

$C_{\psi,{\Gamma_{K}}}({\mathbb{D}}_{K_{p^{\infty}}}^{\dagger})\simeq
C_{\psi,{\Gamma_{K}}}({\mathbb{D}}_{K_{p^{\infty}}}).$

     * •

It remains to compare
$C_{\varphi,{\Gamma_{K}}}({\mathbb{D}}_{K_{p^{\infty}}}^{\dagger})$ and
$C_{\varphi,{\Gamma_{K}}}({\mathbb{D}}_{{\mathrm{rig}},{K_{p^{\infty}}}}^{\dagger})$;
this is implied by $C_{\varphi}({\mathbb{D}}_{K_{p^{\infty}}}^{\dagger})\simeq
C_{\varphi}({\mathbb{D}}_{{\mathrm{rig}},{K_{p^{\infty}}}}^{\dagger})$, as
proved in [Ked08, Prop. 1.5.4].

######  Remark 9.17.

We compare our methods with those in Rem. 9.16.

  1. (1)

The complexes

$C_{\varphi,{\Gamma_{K}}}(\widetilde{{\mathbf{D}}}_{K_{p^{\infty}}})$,
$C_{\varphi,{\Gamma_{K}}}(\widetilde{{\mathbf{D}}}_{K_{p^{\infty}}}^{\dagger})$,
$C_{\varphi,{\Gamma_{K}}}(\widetilde{{\mathbf{D}}}_{{\mathrm{rig}},{K_{p^{\infty}}}}^{\dagger})$

are not often considered in the literature (to the knowledge of the authors).
As we see in Thms 9.5 and 9.9, it is easy to show that they are quasi-
isomorphic to $\mathrm{R}\Gamma({G_{K}},V)$; in addition, this leads to a
rather easy (and conceptual) reproof of comparison with
$C_{\varphi,{\Gamma_{K}}}({\mathbb{D}}_{K_{p^{\infty}}})$. The proofs of all
these results essentially only make use of $\varphi$-operators.

  2. (2)

As recalled in Rem. 9.16(2) above, Liu first treated
$C_{\varphi,{\Gamma_{K}}}({\mathbb{D}}_{K_{p^{\infty}}}^{\dagger})$ using
$\psi$-operator (where the proof requires $[K:{\mathbb{Q}_{p}}]<\infty$), then
he compares
$C_{\varphi,{\Gamma_{K}}}({\mathbb{D}}_{{\mathrm{rig}},{K_{p^{\infty}}}}^{\dagger})$
using ${\varphi}$-operator. We go in a _different_ route. We first treat
$C_{\varphi,{\Gamma_{K}}}({\mathbb{D}}_{{\mathrm{rig}},{K_{p^{\infty}}}}^{\dagger})$
in Step 2 of proof of Thm. 9.9, using _locally analytic vectors_ (which works
for all $K$); we then compare with
$C_{\varphi,{\Gamma_{K}}}({\mathbb{D}}_{K_{p^{\infty}}}^{\dagger})$ in Step 4
there, using ${\varphi}$-operator.

######  Remark 9.18.

We comment on the $\psi$-operators in Construction 8.5.

  1. (1)

In the study of $({\varphi},\Gamma)$-modules, the $\psi$-operator
($\psi_{K_{p^{\infty}}}$ in Construction 8.5) has played a _very_ significant
role.

     * •

A first application of $\psi$-operator is in [Her98, Her01], where he proves
finiteness and duality for cohomology of $({\varphi},\Gamma)$-modules,
_without_ using its relation with Galois cohomology. For example, a key player
in the theory is the _heart_ , cf. [Her98, §3.4]

(9.12)
$({\varphi}-1)({\mathbb{D}}_{K_{p^{\infty}}})\cap({\mathbb{D}}_{K_{p^{\infty}}})^{\psi=0}$

     * •

In the first proof of overconvergence of $({\varphi},\Gamma)$-modules, [CC98]
makes use of $\psi$-operators; however, as shown in [BC08], it is indeed
unnecessary. Rather, overconvergence follows from a general formalism of _Sen
theory_ , as axiomatized in [BC08] and later further in [BC16].

     * •

The $\psi$ operator is a key player in Iwasawa theory. By [CC99, Thm. II.1.3,
Rem. II.3.2], we have

$({\mathbb{D}}_{K_{p^{\infty}}}^{\dagger})^{\psi=1}=({\mathbb{D}}_{K_{p^{\infty}}})^{\psi=1}\simeq
H^{1}_{\mathrm{Iw}}(K,V)$

and

${\mathbb{D}}_{K_{p^{\infty}}}^{\dagger}/(\psi-1)\simeq{\mathbb{D}}_{K_{p^{\infty}}}/(\psi-1)\simeq
H^{2}_{\mathrm{Iw}}(K,V)$

where $H^{i}_{\mathrm{Iw}}$ is the Iwasawa cohomology.

  2. (2)

Moving to the world of $({\varphi},\tau)$-modules, our understanding of the
$\psi$-operator ($\psi_{K_{\infty}}$ in Construction 8.5) is very limited. We
use this opportunity to pose some questions, hoping to come back in future
investigations.

     * •

Can we develop some $(\psi,\tau)$-cohomology theory? If one uses the category
$\mathrm{Mod}_{{\varphi},{\hat{G}}}(\mathbf{A}_{K_{\infty}},{\widetilde{{\mathbf{A}}}}_{L})$,
one quickly finds the problem that $\psi$ is only well-defined on _imperfect_
rings and hence is problematic on the ring ${\widetilde{{\mathbf{A}}}}_{L}$.
Furthermore, say let us first only consider ${\mathbf{D}}_{K_{\infty}}$ over
the imperfect ring $\mathbf{A}_{K_{\infty}}$, and thus one can form the heart
as in (9.12); however practically all methods in [Her98] cannot be applied
here, essentially because ${K_{\infty}}/K$ is not a Galois tower.

     * •

For the proof of overconvergence of $({\varphi},\tau)$-modules in [GL20,
GP21], the $\psi$-operator is never used. In particular, the proof of [GP21]
makes use of the axiomatic (locally analytic) Sen theory developed by [BC08,
BC16].

     * •

Does $\psi$ on ${\mathbf{D}}_{K_{\infty}}$ lead to any “Iwasawa theory”? Note
since ${K_{\infty}}/K$ is not Galois, it is not even clear what should be the
correct “Iwasawa algebra” here. Put in another way, we do not know if
${\mathbf{D}}_{K_{\infty}}^{\psi=1}$ has any interesting module structure.

## References

  * [BC08] Laurent Berger and Pierre Colmez.  Familles de représentations de de Rham et monodromie $p$-adique.  Astérisque, (319):303–337, 2008.  Représentations $p$-adiques de groupes $p$-adiques. I. Représentations galoisiennes et $({\varphi},\Gamma)$-modules.
  * [BC16] Laurent Berger and Pierre Colmez.  Théorie de Sen et vecteurs localement analytiques.  Ann. Sci. Éc. Norm. Supér. (4), 49(4):947–970, 2016.
  * [Ber02] Laurent Berger.  Représentations $p$-adiques et équations différentielles.  Invent. Math., 148(2):219–284, 2002.
  * [Ber08a] Laurent Berger.  Construction de $({\varphi},\Gamma)$-modules: représentations $p$-adiques et $B$-paires.  Algebra Number Theory, 2(1):91–120, 2008.
  * [Ber08b] Laurent Berger.  Équations différentielles $p$-adiques et $({\varphi},N)$-modules filtrés.  Astérisque, (319):13–38, 2008.  Représentations $p$-adiques de groupes $p$-adiques. I. Représentations galoisiennes et $({\varphi},\Gamma)$-modules.
  * [Ber09] Laurent Berger.  Presque ${\mathbb{C}}_{p}$-représentations et $({\varphi},\Gamma)$-modules.  J. Inst. Math. Jussieu, 8(4):653–668, 2009.
  * [Ber16] Laurent Berger.  Multivariable $(\varphi,\Gamma)$-modules and locally analytic vectors.  Duke Math. J., 165(18):3567–3595, 2016.
  * [BMS18] Bhargav Bhatt, Matthew Morrow, and Peter Scholze.  Integral $p$-adic Hodge theory.  Publ. Math. Inst. Hautes Études Sci., 128:219–397, 2018.
  * [BMS19] Bhargav Bhatt, Matthew Morrow, and Peter Scholze.  Topological Hochschild homology and integral $p$-adic Hodge theory.  Publ. Math. Inst. Hautes Études Sci., 129:199–310, 2019.
  * [Bre99] Christophe Breuil.  Une application de corps des normes.  Compositio Math., 117(2):189–203, 1999.
  * [BS22] Bhargav Bhatt and Peter Scholze.  Prisms and prismatic cohomology.  Ann. of Math. (2), 196(3):1135–1275, 2022.
  * [Car13] Xavier Caruso.  Représentations galoisiennes $p$-adiques et $(\varphi,\tau)$-modules.  Duke Math. J., 162(13):2525–2607, 2013.
  * [CC98] F. Cherbonnier and P. Colmez.  Représentations $p$-adiques surconvergentes.  Invent. Math., 133(3):581–611, 1998.
  * [CC99] Frédéric Cherbonnier and Pierre Colmez.  Théorie d’Iwasawa des représentations $p$-adiques d’un corps local.  J. Amer. Math. Soc., 12(1):241–268, 1999.
  * [Col08] Pierre Colmez.  Espaces vectoriels de dimension finie et représentations de de Rham.  Astérisque, (319):117–186, 2008.  Représentations $p$-adiques de groupes $p$-adiques. I. Représentations galoisiennes et $({\varphi},\Gamma)$-modules.
  * [EG23] Matthew Emerton and Toby Gee.  Moduli stacks of étale ($\varphi,\Gamma$)-modules and the existence of crystalline lifts, volume 215 of Annals of Mathematics Studies.  Princeton University Press, Princeton, NJ, [2023] ©2023.
  * [FF18] Laurent Fargues and Jean-Marc Fontaine.  Courbes et fibrés vectoriels en théorie de Hodge $p$-adique.  Astérisque, (406):xiii+382, 2018.  With a preface by Pierre Colmez.
  * [Fon90] Jean-Marc Fontaine.  Représentations $p$-adiques des corps locaux. I.  In The Grothendieck Festschrift, Vol. II, volume 87 of Progr. Math., pages 249–309. Birkhäuser Boston, Boston, MA, 1990\.
  * [Gao23] Hui Gao.  Breuil-Kisin modules and integral $p$-adic Hodge theory.  J. Eur. Math. Soc. (JEMS), 25(10):3979–4032, 2023.  With Appendix A by Yoshiyasu Ozeki, and Appendix B by Gao and Tong Liu.
  * [GL20] Hui Gao and Tong Liu.  Loose crystalline lifts and overconvergence of étale $(\varphi,\tau)$-modules.  Amer. J. Math., 142(6):1733–1770, 2020.
  * [GMW] Hui Gao, Yu Min, and Yupeng Wang.  Prismatic crystals over the de Rham period sheaf.  preprint.
  * [GMW23] Hui Gao, Yu Min, and Yupeng Wang.  Hodge–Tate prismatic crystals and Sen theory.  arxiv:2311.07024, 2023.
  * [GP21] Hui Gao and Léo Poyeton.  Locally analytic vectors and overconvergent $(\varphi,\tau)$-modules.  J. Inst. Math. Jussieu, 20(1):137–185, 2021.
  * [Her98] Laurent Herr.  Sur la cohomologie galoisienne des corps $p$-adiques.  Bull. Soc. Math. France, 126(4):563–600, 1998.
  * [Her01] Laurent Herr.  Une approche nouvelle de la dualité locale de Tate.  Math. Ann., 320(2):307–337, 2001.
  * [HS97] P. J. Hilton and U. Stammbach.  A course in homological algebra, volume 4 of Graduate Texts in Mathematics.  Springer-Verlag, New York, second edition, 1997.
  * [Ked08] Kiran S. Kedlaya.  Slope filtrations for relative Frobenius.  Number 319, pages 259–301. 2008.  Représentations $p$-adiques de groupes $p$-adiques. I. Représentations galoisiennes et $({\varphi},\Gamma)$-modules.
  * [Ked16] Kiran S. Kedlaya.  The Hochschild-Serre property for some $p$-adic analytic group actions.  Ann. Math. Qué., 40(1):149–157, 2016.
  * [Kis06] Mark Kisin.  Crystalline representations and $F$-crystals.  In Algebraic geometry and number theory, volume 253 of Progr. Math., pages 459–496. Birkhäuser Boston, Boston, MA, 2006.
  * [Kis08] Mark Kisin.  Potentially semi-stable deformation rings.  J. Amer. Math. Soc., 21(2):513–546, 2008.
  * [KL] Kiran Kedlaya and Ruochuan Liu.  Relative $p$-adic Hodge theory, II: imperfect period rings.  preprint.
  * [KL15] Kiran S. Kedlaya and Ruochuan Liu.  Relative $p$-adic Hodge theory: foundations.  Astérisque, (371):239, 2015.
  * [Laz65] Michel Lazard.  Groupes analytiques $p$-adiques.  Inst. Hautes Études Sci. Publ. Math., (26):389–603, 1965.
  * [Liu08a] Ruochuan Liu.  Cohomology and duality for $({\varphi},\Gamma)$-modules over the Robba ring.  Int. Math. Res. Not. IMRN, (3):Art. ID rnm150, 32, 2008.
  * [Liu08b] Tong Liu.  On lattices in semi-stable representations: a proof of a conjecture of Breuil.  Compos. Math., 144(1):61–88, 2008.
  * [Liu10] Tong Liu.  A note on lattices in semi-stable representations.  Math. Ann., 346(1):117–138, 2010.
  * [Nak13] Kentaro Nakamura.  Deformations of trianguline $B$-pairs and Zariski density of two dimensional crystalline representations.  J. Math. Sci. Univ. Tokyo, 20(4):461–568, 2013.
  * [Pan22] Lue Pan.  On locally analytic vectors of the completed cohomology of modular curves.  Forum Math. Pi, 10:Paper No. e7, 82, 2022.
  * [Por22] Gal Porat.  Locally analytic vector bundles on the Fargues-Fontaine curve.  to appear, Algebra Number Theory, 2022.
  * [Poy19] Léo Poyeton.  Extensions de Lie $p$-adiques et $(\varphi,{\Gamma})$-modules.  PhD thesis, 2019.
  * [RC22] Juan Esteban Rodríguez Camargo.  Geometric Sen theory over rigid analytic spaces.  preprint, 2022.
  * [RJRC22] Joaquín Rodrigues Jacinto and Juan Esteban Rodríguez Camargo.  Solid locally analytic representations of $p$-adic Lie groups.  Represent. Theory, 26:962–1024, 2022.
  * [RJRC23] Joaquín Rodrigues Jacinto and Juan Esteban Rodríguez Camargo.  Solid locally analytic representations.  preprint, 2023.
  * [Tam15] Georg Tamme.  On an analytic version of Lazard’s isomorphism.  Algebra Number Theory, 9(4):937–956, 2015.
  * [TR11] Floric Tavares Ribeiro.  An explicit formula for the Hilbert symbol of a formal group.  Ann. Inst. Fourier (Grenoble), 61(1):261–318, 2011.
  * [TR12] Floric Tavares Ribeiro.  Sur les représentations absolument naïves et leur module de Wach.  preprint, 2012.
  * [Wan22] Xiyuan Wang.  Weight elimination in two dimensions when $p=2$.  Math. Res. Lett., 29(3):887–901, 2022.
  * [Zha] Luming Zhao.  Herr complex of $(\varphi,\tau)$-modules.  preprint.