Institutional Repository

This document is published in: Annual Workshop on Network and Systems Support for Games (2012) pp.1-2

DOI: 10.1109/NetGames.2012.6404021

© 2012 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. An empirical study of Cloud Gaming

M. Manzano∗, J. A. Hernandez´ †, M. Uruena˜ †, E. Calle∗ ∗Institute of Informatics and Applications (IIiA), University of Girona, Spain †Dept. of Telematic Engineering, Universidad Carlos III de Madrid, Spain ∗{mmanzano, eusebi}@eia.udg.edu, †{jahgutie, muruenya}@it.uc3m.es

Abstract—Online gaming connects players from all over the home connection (802.11n + VDSL), referred to as HOME, world together for fun and entertainment, and has been regarded with 51.01 Mbps of downstream, 5.34 Mbps of upstream, 2 as one of the most profitable and popular Internet services. Be- ms of jitter and 60.08 ms and 25.71 ms of RTT to the nearest sides, there is a growing trend towards moving local applications to remote data centers: this is often referred to as the cloud. With OnLive and respectively. the purpose of studying the impact of Cloud Gaming on the access Results overview. Fig. 1 shows a scatter plot of average network load, in this paper we carry out an empirical network packet rate versus packet size for each game and platform, traffic analysis of two well-known cloud gaming platforms: On- both in the downstream (Fig. 1 (a)) and upstream (Fig. 1 (b)) Live and Gaikai. Traffic traces have been collected and analysed directions. As observed in Fig. 1 (a), OnLive presents a higher from five different games of both platforms. Cloud gaming has been observed to be remarkably different from traditional on- packet rate (in the range between 600 to 750 packet/sec) than line gaming in terms of network load and traffic characteristics. Gaikai (in the range of 350 to 550 packet/sec). This difference Moreover, the traces have revealed similarities between the two is especially remarkable when considering the two racing platforms regarding the packet size distribution, and differences games (nfs and crazytaxy) and the shooter games (crysis2 concerning the packet inter-arrival times. However, each platform and unreal3). It is also worth noting that the 4e game (the shows a similar traffic pattern for most of the games it serves. Nonetheless, the racing and shooter games considered in this OnLive 2D puzzle game) shows different values with respect work demand more bandwidth than other game-genres. to the other games of OnLive. This might be due to the fact that the OnLive platform adapts the bit rate and dedicates less Cloud gaming platforms. OnLive and Gaikai are the two computational resources for a game that does not have high cloud gaming platforms chosen for this study. Their main graphic requirements, as studied in [4]. features are: In the upstream direction (Fig. 1 (b)), packet rates range a) OnLive : According to the official OnLive’s website [1], between 35–65 packets/sec for OnLive and between 10– for a good Quality of Experience (QoE) the platform requires 40 packet/sec for Gaikai. It can be observed that OnLive a minimum bandwidth connection of 2 Mbps to render content does not only have a higher packet rate, but also a higher at 1024 x 576 pixels, recommends 5 Mbps for 1280 x 720, and packet size. This means that OnLive requires a higher network is able to output at 1080p with a higher bandwidth connection. performance than Gaikai. OnLive requires a local installation of its own client. → Client. The measurements regarding the server- b) Gaikai: does not require any local installation since it originated traffic (downstream) are analysed next. Fig. 2 runs on any up-to-date web browser. As stated in its website depicts the packet size CDF for all games and platforms. [2], Gaikai is playable from around 3 Mbps but offers a better According to Fig. 1 (a), it can be observed that in general, performance at 5 Mbps. This platform is also able to output average packet size is smaller for Gaikai. However, in both content at 1080p, yet with higher network requirements. cases a bimodal distribution is observed: OnLive has the low These cloud gaming platforms leverage a GPU on a server mode at about 250 bytes and the large mode around 1400 to render content. OnLive uses an H.264 encoder chip on bytes while Gaikai shows its two modes at 150 and 1480 bytes a dedicated device to grab the video output of each GPU respectively. The packet size related with the large mode for running on their servers. Gaikai uses a CPU to encode H.264. both platforms may be caused due to the MTU (Maximum Both platforms have strong jitter requirements, and are highly Transmission Unit) of the two considered access network sensitive to packet loss and packet delay [3]. scenarios (i.e. Ethernet-based). The difference between both Measurement methodology. Traffic traces of around 100 platforms relies on the fact of which mode is the largest. For seconds (wall clock) of playing time have been captured at Gaikai the largest mode is the one related with small packets the local computer of the gamer. Each traffic trace records (150 bytes), whereas for OnLive the largest mode is for large the packet size and inter-arrival times of all captured packets. packets (1400 bytes). Obviously, this fact makes a difference Measurements have been carried out from two different access in the average packet size observed in Fig. 1. network scenarios: (a) a wired University connection (100 Concerning inter-arrival times of both cloud gaming plat- Mbps Fast Ethernet), referred to as UNIV, with 94.17 Mbps of forms, as observed in Fig. 3, in OnLive about 40% of packets downstream, 71.81 Mbps of upstream, 1 ms of jitter and 38.12 show inter-arrival times within microseconds (µs), which ms and 25.28 ms of RTT (Round-Trip Time) to the nearest are then uniformly distributed up to 5 ms. Moreover, it is OnLive and Gaikai data center respectively; (b) and a wireless interesting to note that Gaikai shows three modes: 20% of

1 1100 1 OnLive−Uni crazytaxy crazytaxy 0.9 1000 OnLive−Home Gaikai−Uni unreal3 unreal3 Gaikai−Home airconflicts 0.8 pes2012 airconflicts 900 pes2012 0.7

0.6 800 nfs crysis2 nfs 4elements 0.5 Onlive−PES2012 4elements CDF Onlive−Unreal3 700 fifa2012 0.4 Onlive−Crazytaxy Packet size (bytes) fifa2012 Onlive−AirConflicts crysis2 crazymachines2 Onlive−4elements 0.3 600 combatwings Gaikai−FIFA2012 combatwings Gaikai−Crysis2 crazymachines2 0.2 Gaikai−NFS Gaikai−Combatwings 500 0.1 Gaikai−CrazyMachines2

0 400 0 1 2 3 4 5 6 7 8 9 10 300 350 400 450 500 550 600 650 700 750 Inter−arrival time (ms) Packets/sec (a) Server → Client Fig. 3. Server → Client: CDF of packet inter-arrival times (ms). 180

crazytaxy pes2012 pes2012 1 unreal3 160 airconflicts airconflicts 0.9 crazytaxy 4elements

unreal3 4elements 0.8 140 0.7

0.6 120 0.5

crysis2 CDF Onlive−PES2012 Onlive−Unreal3 0.4 crysis2 Onlive−Crazytaxy

Packet size (bytes) 100 nfs combatwings Onlive−AirConflicts crazymachines2 0.3 Onlive−4elements combatwings Gaikai−FIFA2012 Gaikai−Crysis2 fifa2012 crazymachines2 0.2 80 OnLive−Uni Gaikai−NFS fifa2012 nfs OnLive−Home Gaikai−Combatwings 0.1 Gaikai−Uni Gaikai−CrazyMachines2 Gaikai−Home 60 0 0 50 100 150 200 250 300 350 400 Packet size (bytes) 0 10 20 30 40 50 60 70 80 90 100 Packets/sec (a) CDF of packet size (bytes)

(b) Client → Server 1

Fig. 1. Packets/sec vs average packet size for the downstream (a) and the 0.9 upstream (b) directions. 0.8

0.7 1 0.6

0.9 0.5 CDF Onlive−PES2012 0.8 0.4 Onlive−Unreal3 Onlive−Crazytaxy Onlive−AirConflicts 0.7 0.3 Onlive−4elements Gaikai−FIFA2012 0.6 0.2 Gaikai−Crysis2 Gaikai−NFS 0.1 Gaikai−Combatwings 0.5 Gaikai−CrazyMachines2 CDF

0 0 2 4 6 8 10 12 14 0.4 Onlive−PES2012 Inter−arrival time (ms) Onlive−Unreal3 0.3 Onlive−Crazytaxy (b) CDF of packet inter-departure times (ms) Onlive−AirConflicts Onlive−4elements 0.2 Gaikai−FIFA2012 Gaikai−Crysis2 Fig. 4. Client → Server: CDF of packet size (a) and CDF of packet inter- Gaikai−NFS 0.1 Gaikai−Combatwings departure times (b). Gaikai−CrazyMachines2

0 0 200 400 600 800 1000 1200 1400 1600 Packet size (bytes) better understanding of the underlying protocols used by the Fig. 2. Server → Client: CDF of packet size (bytes). two platforms. Moreover, network conditions could be altered (i.e. adding delay) in order to evaluate its consequences on the packets arrive within few µs, 50% around 1 ms, and the Quality of Experience perceived by gamers. remaining 30% near 4 ms. Acknowledgment. This work is partly supported by the Client → Server. We have performed the same analysis projects TRION (TEC 2009-10724), FIERRO (TEC 2010- for the client-originated traffic (upstream). Fig. 4 (a) presents 12250-E) and Medianet (S-2009/TIC-1468); and by the Gen- the packet size CDF. Gaikai shows modes between 50 to 100 eralitat de Catalunya through the research support program bytes, whereas OnLive shows modes in 100 bytes, 140 bytes project SGR-1202 and AGAUR FI-DGR 2012 grant. and 240 bytes approximately. To conclude, Fig. 4 (b) shows the REFERENCES inter-departure times CDF. In this case, Gaikai shows a mode below 1 ms and then uniformly distributed inter-departure [1] Onlive, http://www.onlive.com, [Online; accessed 25-July-2012]. [2] Gaikai, http://www.gaikai.com, [Online; accessed 25-July-2012]. times up to 12 ms. On the contrary, OnLive shows uniformly [3] M. S. Borella, “Source models of network game traffic,” Computer distributed inter-departure times from 0 to 8 ms and then a Communications, vol. 23, no. 4, pp. 403–410, 2000. mode at around 9 ms. [4] K.-T. Chen, Y.-C. Chang, P.-H. Tseng, C.-Y. Huang, and C.-L. Lei, “Measuring the latency of cloud gaming systems,” in Proceedings of ACM Future work. It could be interesting to further investigate Multimedia 2011, Nov 2011. cloud gaming-generated traffic with the purpose of having a

2