# Secure Partitioning of Cloud Applications, with Cost Look-Ahead
## 7 Experimental Assessment
### Discussion of the Results
As K grows over seven the future cost is stabilised at about \(14.6\) work hours. For partitioning with five domains, the behaviour depends on the application architecture as before and we record a minimum future cost of \(0\) work hours for every K. The partitioning with full isolation, having six domains, always has zero future cost._  
Finally, we have to answer the question  
**Q4:**_How much do K and DLimit impact the probability of not having a safe partitioning?_  
A labelling does not have a safe partitioning when the application is non-safely partitionable or \(DLimit\) is less than the possible configuration of software component labels. We recall that an application is non-safely partitionable when it has untrusted hardware or when there is an untrusted path toward the hardware. When \(K\) grows the number of labellings grows exponentially; thus, the probability of having a non-safely partitionable application also grows. This is shown in Figure 11; the three lines grow with K. The growth is bigger at the start, then decreases around \(K\) equal to seven. This happens because it is enough to have a few _bad_ labels to have a non-safely partitionable application that can be mitigated with several others. For instance, to make a hardware component untrusted it is enough to have one low characteristic and to make it trusted again all the data need to be low as well. The lower bound of domains to satisfy all the possible labellings is six. In general, the probability of finding non-satisfiable labellings grows until \(DLimit\) reaches the lower bound. For this reason, the figure shows that having the lowest value of \(DLimit\) (four) increases the probability of finding non-satisfiable labellings. With \(DLimit\) equal to five this does not happen because the labellings that are satisfiable only by six domains make the application non-safely partitionable. Thus, the orange and green lines are overlapping. To summarise, having a low value of \(K\) brings a lower probability of not finding a safe partitioning. When the starting labelling makes the application safely partitionable, having few changes does not increase drastically the probability of making it safely partitionable. Instead, having a low value of \(DLimit\) brings a higher probability of not finding a partitioning that satisfies a labelling until the lower bound on the number of domains is reached. To summarise, _the probability of not having an application safely partitionable is the lowest with K equal to one for every \(DLimit\), being about \(0.175\). With K equal to \(13\) the probability reaches the maximum of \(0.538\) with \(DLimit\) equal to four and \(0.519\) both with \(DLimit\) equal to five and six._  
As a final remark, our methodology has the benefit of(i) determining secure deployments of multi-component applications and (ii) proposing different solutions to allow the application operator to choose the trade-off between SK impact and future deployment changes. The main drawback of our methodology resides in the high execution time to handle instances in which applications have several components and a high number of data types and characteristics. To overcome this drawback we give the opportunity to select the \(K\) and \(DLimit\) parameters to reduce the execution time. According to our experiments:  
* Low values of \(K\) are suitable to handle problem instances that are likely to incur in a few label changes (e.g., 1-3). In such cases, selecting a low value of \(K\) can drastically reduce the execution times, contain future costs and reduce the probability that an application will not be safely partitionable in the future. * The decision on setting the value of \(DLimit\) is less immediate. Low values are suitable to reduce ProbSKnife's execution time. Instead, high values reduce the future costs and the probability of incurring in a non-safely partitionable application.