# Survey on Quality of Experience Evaluation for Cloud-Based Interactive Applications
## 5 Strategies for QoE Measurement in CIAs
### Strategies Based on the Use of Slow-Motion Benchmarking  
Among the strategies available in the literature, one stands out: slow-motion benchmarking from [PERSON] et al. [49]. Slow-motion benchmarking is a methodology for obtaining interactivity time for remote desktop CIAs from network traffic. Slow-motion benchmarking estimates interactivity time from patterns of network packets exchanged by both ends. When a user interacts with an application via a desktop, the thin client sends a request to the cloud server. This request generates an increase in network traffic. When the application located on the cloud server produces a response, it sends it to the thin client, again generating a spike in network traffic. Slow-motion benchmarking monitors this network traffic to obtain the elapsed time between the two traffic surges. If slow-motion benchmarking captures the traffic near the thin client, that elapsed time approximates the time between when a user interacts via a keyboard or mouse with the thin client and when they perceive a response on the screen. However, to avoid problems in detecting increased network traffic, slow-motion benchmarking requires a single ongoing request to the cloud server. This methodology requires instrumenting the thin client to refrain from initiating a new user interaction until it receives a response to the previous request. Therefore, it is not suitable for measuring the QoE of a user in real time but only serves to characterise the scenario under controlled conditions. The authors suggested two safeguards for implementing the methodology. The use of a remote desktop protocol generates approximately constant traffic due to the communication between the thin client and the cloud server. An increase in this traffic may confuse the base traffic of the protocol used with the traffic generated by user integration. An implementation of the methodology must take this fact into account and establish a threshold above which it considers the detection of an interaction. Furthermore, the authors stated that the interactivity time obtained by slow-motion benchmarking is an approximation. The methodology does not consider the time that the thin client employs to detect the user interaction or to prepare and send the interaction over the network, nor does it consider the time that the client needs to reflect the detected update in the network traffic on the screen. Several proposals used slow-motion benchmarking as the core of their research. Among them is the work carried out by [PERSON] et al. [51]. The authors proposed a tool (VDBench) to evaluate and compare different remote desktop solutions. VDBench is based on slow-motion benchmarking and offers the interactivity time obtained from synthetic user interactions (as it does not come from real-time users). In addition, it offers test automation to evaluate the scalability of virtual machines on the cloud server. VDBench collects metrics on bandwidth usage, network loss, CPU, and RAM. Other authors chose to use slow-motion benchmarking to quantify the performance of different remote desktop solutions in their studies. [PERSON] et al. [33] referred to VD-DUT as the synthetic interactivity time obtained by slow-motion benchmarking. They also supplemented it with other metrics to assess the visual and sound quality experienced by users. In their study, 115 participants used four applications (image viewing, Skype, 3D image viewing, and video playback) via Windows RDP. In their study, they modified network conditions to generate packet losses while users interacted following the principles set by slow-motion benchmarking for a single network interaction. They simultaneously correlated objective measurements of visual quality, sound quality, and VD-DUT with opinion values by questioning the users under various boundary conditions defined by the authors. The work of [PERSON] et al. [33] used the MOS scale. Therefore, there are some disadvantages common to proposals employing slow-motion benchmarking.