ces are based on the TCP/IP protocol stack which ensures 100% lossless transfer, but it is directly dependent on the RTT due to TCP congestion control mechanisms (e.g. Slow Start, Congestion Avoid- ance). End-to-end delay is hard to measure for cloud services because the cloud data may traverse multiple network segments belonging to multiple telecom operators in different countries, SO this metric is one of the least predictable since it does not depend only upon the access bitrates (and QoS being in force) on the side of the CSC or the CSP, but also is influenced by the transit networks. One may note that most of the QoS-supported cloud services are provided inside the telecom operator's network (e.g. the telecom operator is also the cloud provider), while in other cases when the CSP is a third party the cloud services are provided as OTT services (which can be charged by the CSP or given free of charge with certain data cap or/and time duration). However, with the development of ultra-broadband access networks, which typically are connected to core and transport networks that can support such ultra-broadband speed (based on proper traffic dimen- sioning), the low end-to-end latency can become reality for the cloud services. As is the case for most of the client-server interactive service, the delay is also influenced by the time required for the signals to travel between the client and the server with the speed of light (that is 3x108 m/s), which gives delays in the range of 100 ms when the client and servers are on the opposite sides of the globe (e.g. the perimeter of the Earth is around 40 000 km on the Equator, SO half of the perimeter is 20 000 km, and the transmission path terrestrially will be significantly longer than 20 000 km, e.g. 30 000 km). So, to have lower RTT, most of the OTT service providers, and particularly OTT cloud services (e.g. video sharing sites such as YouTube, Amazon cloud services, social networking services) use CDNs which are located closer to the end-users in order to reduce the 