## 4 SLA Specification for the Fog Storage Services
### SLA Parameters
#### 4.4.3 Cost  
Cost is another important SLA parameter. Public Cloud storage providers define several separate cost units: storage cost, operation cost, data transfer cost, storage API access cost, Content Delivery Network cost, early object deletion penalty, transfer acceleration cost and other costs. Deriving cost as a single amount billed per month to a user for storing and using a file requires compounding of the individual cost units with the respective information about the file size, the number of read and write operations, the file life-span and so on. In addition to that, commercial Cloud storage providers usually implement a multi-tariff block pricing model [52], in which the storage cost per stored byte decreases for larger accrued amount of stored data. As a result, modelling cost precisely is overly complex and for our purposes unnecessary, yet we do agree that a different cost model could affect the results presented in this work. The complexity is likely one of the reasons why in the literature cost models vary significantly. For a fine-grained cost model, we refer the reader to the work of [PERSON] et al. [53]. However, in their work, the pricing model specifically targets the pricing schemata of commercial Clouds or, in more general terms, the schemata that follow such a model.  
In the literature, there is no common definition of cost models for Fog environments to be found. In the context of this work, we define cost as a composition of three cost parameters: (1) storage cost \(c_{s}\), which is the price that the user has to pay to the storage provider for storage of data on the Fog node; (2) data transfer cost \(c_{t}\), which is the accrued transferred amount of bytes per some time unit; and (3) operation cost \(c_{o}\), which is the cost of read and write operations (i.e., API call costs) per time unit.  
Given a file \(f\), which has to be stored over time \(t\) in storage \(s\). Then, the cost of storing \(c_{s}\) can be expressed as  
\[c_{s}(s,f,t)=t\cdot\text{size}(f)\cdot c_{s}(s), \tag{1}\]  
where \(\text{size}(f)\) designates the size of file \(f\) in GB, time \(t\) is measured in months and \(c_{s}(s)\) is the unit storage price of storage \(s\), expressed in a chosen currency per GB per month.  
Furthermore, the data transfer cost \(c_{t}\) for transferring file \(f\) from storage \(s\) to client \(p\) is defined as follows:  
\[c_{t}(s,p,f)=\text{size}(f)\cdot c_{t}(s,p) \tag{2}\]  
with \(c_{t}(s,p)\) designating the unit cost per GB for transferring data from storage \(s\) to client \(p\). It is a common practice among commercial Cloud providers to only charge for downstream transfers while keeping the upstream transfers free of charge. Thus, without sacrificing the practicality, we follow the same assumption.  
The operation cost \(c_{o}(s)\) refers to the cost of a single request for read or write operation. Most often, a batch of bytes is read or written in a single API call.  
Finally, by combining the storage cost, data transfer cost and operation cost, the accrued cost of storing and accessing file \(f\) in storage \(s\) from client \(p\) over time \(t\) is expressed in the following way:\[c(s,p,f,t)=\] \[c_{s}(s,f,t) \text{(cost for storing)}\] \[+n_{r}\cdot(c_{t}(s,p,f)+c_{o}(s)) \text{(cost for reading)}\] \[+n_{w}\cdot c_{o}(s) \text{(cost for writing)}\]  
with \(n_{r}\) read and \(n_{w}\) write API calls. In our case, we assume that the SLA is defined separately for each file (thus we know its size) and that the client \(p\) is known in advance. In addition, we assume that the number of reads \(n_{r}\) and writes \(n_{w}\) are also known, or at least, we know their tight upper bounds. In an SLO, this cost parameter is expressed as an accrued cost per month. One may see such a definition of cost also as a monthly budget for storing and accessing file \(f\), although it may happen that the budget is exceeded if the respective SLO is violated.