3.1. Time Scale Dataset Features
In this section, we will review the context and the significant features of the captures we have taken. All the time plots, reflected in this section, were created by accumulating the packets of respective trace per 1-second intervals.
For “Half-Life: Alyx” and Google Earth, apart from checking the data consumption over real gameplay time, we intended to figure out whether connecting the headset to the PC with the cable eliminates the traffic from the headset itself (Wi-Fi on the headset was activated during all the measurements) so that any interaction with the game server will happen only via PC. We have recorded separate traffic for both respective IP addresses and, in the results, we see that headset traffic has been present; however, it had a lower volume and a different set of protocols than the one observed on the PC (protocol details will be reviewed further in this section).
The following three traces of time-plots are reflected in
Figure 2:
- 1.
Trace 1. A complete gameplay of “Half-Life: Alyx” with launch, going through the game scenario and saving the progress. This is not the first time this game is played on this PC (which means the peak of traffic related to the first launch on this PC is omitted), and no user experience issues are noticed during the session.
- 2.
Trace 2. The same as above but, during the game, from the beginning and up to 5000 s, there was a file upload in the same network with a rate close to the uplink channel bandwidth (20 Mbit/s). The level of user experience disruption: the user was able to continue playing the game but he experienced delays in actions or scene changes from time to time. No game interruptions happened.
- 3.
Trace 3. The same as above but, around the 500th second of the record, we introduced a 100 ms downlink delay, causing user experience degradation (delays in viewing the next scene or doing some user action). As per the user, issues were worse than with the Trace 2 case.
We can see from the traces that “Half-Life: Alyx”, a single-player game with potentially no need to download anything about other players’ status, still generates a fair amount of traffic both in uplink and downlink directions.
Each of the captures contains a short traffic peak related to the game launch and loading of the previous game status and the more stable piece related to the game process itself. Only part of the downlink traffic has equally distributed bursts. The uplink has no regular sequence at the time plot and only depends on the gaming scene and user activity.
One trace was collected for
Google Earth traffic, and the time-plot is reflected in
Figure 3. During the session’s first 300 s, the user passed the tutorial on how to use the environment. Then he explored the globe, zooming in on several continents and, within those, several streets in street walking mode.
As with Half-Life traffic, we can see both headset and the PC portion. But, again, there are no regular patterns in the time plot, and traffic volume depends only on the user activity in both uplink and downlink.
Rec Room has two traces available for the analysis, and their time plot is reflected in
Figure 4. Due to the fact that in some reviewed papers [
17] the traffic captures have been presented from the moment when the user logs into Steam Hall, including choosing the game and lasting to some middle point in the gameplay, we decided to capture all possible phases of user activity, including first and second launch of the game, and see how they can be different and whether mentioned data volumes persist over all user experience steps.
- 1.
Trace 1 contains the first launch of the game. The first 800 s of the trace include launching the game and passing the tutorial, and the rest of the capture consists of user multiplayer activity. The period of watching the tutorial is eliminated from the first graph as it did not generate significant traffic; however, the corresponding data points are presented in the data files.
- 2.
Trace 2 contains the second launch of the game. The first 220 s of the trace include game launch and browsing game options, then 250 s of the multiplayer gaming activity follow, and then the user again returns to browsing game options.
Figure 2.
“Half Life: Alyx” traces for three measurement conditions. (a) Headset traffic, Trace 1, (b) PC traffic, Trace 1, (c) Headset traffic, Trace 2, (d) PC traffic, Trace 2, (e) Headset traffic, Trace 3, (f) PC traffic, Trace 3.
Figure 2.
“Half Life: Alyx” traces for three measurement conditions. (a) Headset traffic, Trace 1, (b) PC traffic, Trace 1, (c) Headset traffic, Trace 2, (d) PC traffic, Trace 2, (e) Headset traffic, Trace 3, (f) PC traffic, Trace 3.
Figure 3.
Google Earth traffic. (a) Headset traffic, (b) PC traffic.
Figure 3.
Google Earth traffic. (a) Headset traffic, (b) PC traffic.
Figure 4.
Rec Room traffic. (a) Trace 1, first launch period of the game, (b) Playing period of Trace 1, (c) Playing period of Trace 2.
Figure 4.
Rec Room traffic. (a) Trace 1, first launch period of the game, (b) Playing period of Trace 1, (c) Playing period of Trace 2.
For Beat Saber, two traces are included in the dataset:
- 1.
Trace 1. A complete gameplay of not the first launch of the game. The first 300 s include the launch of the game and all other time includes regular multiplayer activity. The plot of this trace is reflected in
Figure 5;
- 2.
Trace 2 contains a multiplayer game where we limited the bandwidth for uplink and downlink in steps. The plot for this trace will be presented later in the bandwidth limitation section.
Figure 5.
Beat Saber traffic, Trace 1.
Figure 5.
Beat Saber traffic, Trace 1.
One trace was collected for
VR chat traffic. During the captured time, the first 800 s of the trace correspond to two people chatting, and further observed peaks of the load displayed in
Figure 6 represent several multi-user room talks.
3.2. Traffic Distribution and Protocols
All the measured activities are very different, not only in time scale. In order to assess the possibility to create one traffic model, describing all the mentioned activities at once, we plotted the Cumulative Distribution Function (CDF) of all five types of applications, shown in
Figure 7. Those CDFs had been built using the central parts of the captures. It lets us revise only target user activity and not consider startup traffic peaks or time of browsing options inside the game. Pieces of traces, mentioned in
Table 3, had been taken for every activity to plot CDFs. Packets within each piece were accumulated per 1 s interval to calculate CDF. In a further analysis, we only account for smoothed traffic peaks, not considering the local maximums within each second interval.
We can conclude that it is not possible to make even one model type fitting all games, as only two games, Beat Saber and Rec Room, have a similar form of traffic distribution, varying only in their Probability Density Function (PDF) maximum in the downlink. “Half-Life: Alyx” has the same range of traffic values as those two games, but the distribution is much more skewed to the smaller values.
The range of traffic per second values for Google Earth and VR Chat in the downlink is almost 50 times bigger than for the Beat Saber, Rec Room, and “Half-Life: Alyx”. But VR Chat CDF has a thicker right tail than Google Earth, primarily because of the difference between various user activity traffic rates within one application. For example, if browsing different Earth regions and zooming over those regions in Google Earth does not give a 2–3 times traffic increase per second, in VR Chat, the talk of two people and several people in the room can differ ten times in traffic value. So the distribution of the particular user session in VR Chat will heavily depend on what the user will do during that session.
If we review the protocol stack of all the applications, we can see that PC-rendered games have a far more significant number of protocols involved in the transmission. The major protocols, which are used to handle the user traffic for “Half-Life: Alyx” and Google Earth are TCP, SSL, TLSv1.2 (Transport Layer Security), TLSv1.3, and UDP (User Datagram Protocol). Some notifications from the game server have been transferred with HTTP (Hypertext Transfer Protocol). QUIC protocol had been used at the moments of the biggest UDP bursts to speed up the transmission (only several big bursts of QUIC over each record), SSDP (Simple Service Discovery Protocol) for the discovery and advertisement of services within the network, and MDNS (Multicast Domain Name System) for locating devices in a local network without using a standard DNS (SSDP and MDNS have regular bursts coming in a fixed interval of time).
As we have mentioned in
Section 3.1, the set of protocols for the headset (TCP, TLSv1.2, TLSv1.3) is different from the one on the PC (TLSv1.2, TCP, MDNS, TLSv1.3, UDP, SSDP, QUIC, HTTP, SSLv2, TLSv1) for the tethered setup. We did not find a reason for this split in the references, but having in mind that Client Key Exchange, Change Cipher Spec, and Encrypted Handshake messages can be seen multiple times in both monitored IP traces, and UDP/QUIC only in the PC one, we can suppose that user authentication in Oculus is verified continuously over the gaming session from both tethered devices and gaming progress was saved only from the PC.
For the VR headset-rendered games, the list of protocols shrinks and does not contain SSDP, MDNS, HTTP, or QUIC, as there is no need anymore to interact between several devices or services within the same network and also to visualize the game video on the regular monitor in parallel with the visualization on the headset as is done for PC-rendered games.
Table 4 and
Table 5 list protocols for each game, their average packet size, and their share of overall traffic in the uplink or downlink directions for the respective game.
For further modeling activity, it will be interesting to check which protocol dominates in the transmission as traffic behavior changes with it. For the PC-rendered games, the TCP and TLS traffic take the lead position in both uplink and downlink, leaving a very insignificant share for UDP, while for VR headset-rendered activities, the picture changes. For the games like Rec Room and Beat Saber, UDP traffic share is more than 95% in the downlink, while in the uplink, it drops to 56–65%, leaving all the other parts to TCP and TLS. Finally, VR chat based on the protocol split pattern belongs to the third major group of activities. Its traffic pattern includes mostly TCP/TLS traffic, only 1/3 uplink traffic and 2.5% of downlink goes over UDP.
Another check made with the captured data was the proportion between uplink and downlink traffic at the stable usage period, reflected in
Table 2.
Table 6 demonstrates the result of this check. Surprisingly, the uplink traffic share leader is a single-player game, Half-Life: Alyx, rendered on a user’s PC. It does not download almost anything from the gaming server but uploads a lot. Among the upload content there are backups of the user status and artifacts which he had gathered during the game on the Steam server and, if for any reason the internet speed was limited during the game, the game synchronizes its data with the server at the end of the user session, as is seen in the graph
Figure 2d.
For prediction of the share of the uplink traffic, it may not be enough to know whether the game is multiplayer or single-player and whether it has simple graphics or advanced, as can be seen in
Table 6. For example, Multiplayer Rec Room and Beat Saber have a lower uplink load than single-player Half-Life. Google Earth has almost the same share value as VR Chat, while it has much more advanced video flow. Both of those activities are not symmetric and have the highest downlink share among others. The interesting fact is that the uplink portion is the biggest for the two most popular VR activities: Half-Life: Alyx and Beat Saber. Investigation into the reasons for this can be the topic of further research.
3.3. Bandwidth and Latency Modification
We performed a short test to check what happens with the different types of traffic while we are limiting its bandwidth or introducing some latency.
Figure 8 shows changes in the CDF of the traffic of Half-Life: Alyx, which has TCP-dominating traffic when we introduce the uplink bandwidth decrease (Trace 2) or introduce downlink latency (Trace 3).
In the first experiment, we introduced a big file upload from another user in parallel to the game for 5000 s; it appeared to be a slightly more significant number of small packets than in a typical situation in the uplink. The tail of the distribution became longer, which is more considerable for downlink than for uplink, but the form of the traffic distribution was the same. The average bitrate for the uplink in Trace 2 decreased from 80.9 kbps in Trace 1 to 58.5 kbps and, in the downlink, the bitrate increased from 10.5 kbps to 24.5 kbps, most probably to enable TCP retransmits to happen.
In the second experiment, we injected a 100 ms delay to the downlink using Raspberry PI, which we inserted instead of the Wi-Fi AP depicted in
Figure 1. This time, it appeared to be a slightly lower number of small packets than typically in the uplink, and the tail of the distribution became a little longer for both uplink and downlink. As a result, the average bitrate for the uplink in Trace 3 increased to 138.7 kbps compared to Trace 1 and, in the downlink, the bitrate increased to 13.3 kbps.
As mentioned in the description of Trace 3, the user experience became incompatible with the user expectations exactly in the latency-related experiment, and we can also see from the data above that introducing latency in the TCP-dominated traffic generates, in fact, an increase of the bitrate, which can be measured and controlled. If the decrease of the bitrate in the uplink was correlated with the user inconvenience, the growth of the uplink bitrate was coupled with the substantial user issues during the game.
Another experiment was carried out with the UDP-dominated traffic for Beat Saber. Using the Rasp AP application, the bandwidth was gradually changed step by step, either in uplink or downlink, to allow us to check which part of the channel makes a more considerable difference. We reflected bandwidth changes steps in
Figure 9.
During the experiment, the user had not experienced any issues or delays (even when the load peaks were limited) until the downlink speed reached 150 kbps, the average rate of downlink UDP packets for multiplayer Beat Saber traffic. As soon as we set this limit, the user started to see the delays of other players’ actions for about 2 s. For example, he observed the changing of positions of other players in “jumps”.
The average bitrate in the interval of highest limitation (150 kbps in downlink and same in uplink) had increased in the downlink to 146.6 kbps from 111 kbps in Trace 1 and dropped in the uplink to 60 kbps from 83.8 kbps in Trace 1. The effect of Beat Saber uplink- and downlink-combined limitation was similar to the restriction of uplink bandwidth in Half-Life: Alyx: an increase of transmission in the downlink and a decrease in the uplink. The effect volume was twice as small, probably due to the prevalence of UDP traffic in Beat Saber and the different packet loss handling processes.