ICICS-PCM 2003
15-18 December 2003
Singapore
3B6.8
Traffic Analysis of Internet-based
Multiplayer Online Games from a Client Perspective
John C. McEachen
Department of Electrical and Computer Engineering
Naval Postgraduate School
Monterey, California 93940
USA
[email protected]
Abstract—An analysis of self-similarity in traffic generated by
the popular Internet-based online game engine, Unreal Engine, is
presented. Client-side packet traces are collected and analyzed
for both client and server traffic. Initial analysis of over two
million packets indicates client generated traffic shows strong
long-range dependence of a self-similar nature primarily due to
packet interarrival times associated with user actions. On the
contrary, server generated traffic seen at the client, while still
exhibiting a heavy tail, is more short-range dependent in regions
where self-similarity is observed.
for the U.S. Department of the Army by the U.S. Naval
Postgraduate School. AAO is part of a new class of games
referred to as “advergames” – the U.S. Army gives the game
away for free for recruitment purposes and to foster increased
understanding of Army operations [4]. As of April, 2003,
AAO had 1.3 million registered users, 27% of which were
believed to be outside the United States. Figure 1 shows a
sample screenshot of users participating in a game.
Index Terms—Massively multiplayer online games (MMOG),
self-similarity, statistical analysis
1. Introduction
S
INCE the introduction of Meridian 59 in 1995 and later
Ultima Online (UO) in 1997, massively multiplayer online
games (MMOG) have seen a tremendous level of growth and
development.
Today, most MMOGs, such as Sony’s
Everquest, Asheron’s Call, and UO are subscription-based,
charging a monthly fee for participation. MMOGs are part of
a more general class of software called massively multiuser
persistent worlds (MMPW). The persistent attribute of
MMOGs is perhaps its most defining attribute. The MMOG is
persistent in that players continue to play, develop
capabilities, and evolve in general whether or not the
individual player is logged on to the game. [1]
As [1] argues, MMPW may well revolutionize many facets
of social interaction extending far beyond the limits of gaming
and entertainment. MMPWs appear to have significant
potential in areas of conferencing, training, and general
simulation. Already, the U.S. Department of Defense has
made significant investments in this type of technology for
training members of its armed services [2]. If this inevitable
proliferation of MMOG use holds true, it will have a
significant impact on network design and performance.
Consequently, this paper aims to provide a better
understanding of the behavior of traffic that is associated with
these types of simulation environments.
In this paper, one of the more popular Internet-based online
games, America’s Army: Operations (AAO) is analyzed [3].
AAO is a first person shooter (FPS) loose MMOG developed
0-7803-8185-8/03/$17.00 © 2003 IEEE
Fig. 1. A screenshot from America’s Army: Operations. The soldiers in the
doorway on the left are other players on the same team controlled from
various locations on the Internet. (Courtesy of the U.S. Department of the
Army)
AAO can simultaneously support approximately 186,000
users, although users are actually divided into games – or
shards – of 20 – 50 users [2]. Compare this to Everquest
which recently announced the support of 118,000
simultaneous users in shards of 3,000 users each [1].
Unreal Engine
The actual underlying software engine for AAO is a
commercial, open-source product called Unreal Engine,
developed by Epic Games Inc. of Raleigh, North Carolina.
Unreal Engine is a very popular gaming engine used in
number of successful MMOGs including Tom Clancy’s
Splinter Cell, Unreal Tournament (UT), UT2003, Star Trek,
the Next Generation: Klingon Honor Guard, Duke Nukem
Forever, Rune, Navy Seals and several others.
Unreal Engine is based on a centralized architecture.
Clients connect to a single centralized server and send the
server updates corresponding to player actions such as
movement, weapons firing, etc. The server in turn forwards
information consolidated from other clients as to player
positions and actions.
All Unreal Engine exchanges,
including user authorization, are conducted using UDP.
Related Efforts
In [5] the collected traffic statistics of the LAN-based
games, QuakeWorld (a LAN-based multiplayer extension of
Quake) and Starcraft are presented. The paper observes
observation the same packet size distribution generated by
clients as is presented below, however, the authors do not
present any statistical analysis of the traffic beyond anecdotal
discussion of the observed traces. Another study of a LANbased implementation is discussed in [6]. Although the data
set under consideration is considerably smaller, the study
presents a more rigorous statistical analysis of the traffic and
presents potential source models for generating simulated
traffic. The results of [6] differ from those observed in this
paper for Internet-based traffic, particularly in the case of
client generated traffic which was deterministic in packet size
and produced a more exponentially oriented interarrival time
distribution. More recently, in [7] another method for source
modeling of LAN-based traffic of the game Starsiege Tribes
is presented.
In this paper, the characteristics of an Internet or WANbased game are examined exclusively. The effect of WAN
transport networks on IP traffic has been extensively
discussed (e.g. [8]). Consequently, it would be reasonable to
assume that the characteristics of WAN-based MMOGs would
be different than those seen in the LAN environment. This
paper specifically looks at traces observed from the position
of the client because it was assumed that this would be the
location most likely to observe the cumulative effect of WANbased variations on the traffic of interest.
message. Generally, a single action corresponding to the
press of key correlates with the transmission of a UDP packet
to the server. Consequently, the size of packets tends to be
relatively small with limited variation. Figure 1 shows a plot
of the distribution of packet sizes for a sample of 32,000
packets. Note how the range of packets is limited to between
49 and 111 bytes.
Fig. 1. Distribution of packet sizes generated by the Unreal Engine client.
Fig. 2. Logarithmic distribution of interarrival times for client generated
packets.
1. Experiments and Analysis
Unreal Engine traffic was collected using tcpdump at
microsecond resolution off a mirrored port of a client
connection to a Fast Ethernet (100BaseT) LAN in Monterey,
California, USA. Servers were located seventeen IP hops
away in Atlanta, Georgia, USA. The client machine was a 2.6
GHz Pentium 4 with 512MB or RAM. To date over two
million packets have been analyzed of three different users
playing AAO in shards of 20. The figures below typically are
representative illustrations of 32,000 packet samples from the
overall collection. Aggregate analysis, however, was
performed on the entire collection of traces.
Client generated traffic
The Unreal Engine translates keyboard and mouse input
from the user into actions taken in the game environment such
as walking, turning, firing weapons or communicating via text
Fig. 3. A close-up view of the tail of the interarrival time distribution shown in
figure 2.
Note the number of outliers in the tail in figure 2. In this
example there is almost a bimodal element associated with the
range on the right of the illustration. This particular player
would often pause or hide in waiting to ambush other players.
Consequently a large variation between interarrival times
could be observed.
The left side of figure 4 illustrates the aggregate service rate
of traffic generated by the client over time for different
aggregated time series. From the illustration it can be seen that
there is a strong correlation existing at all resolutions.
Figure 2 and 3 illustrate an example of the distribution of
interarrival times associated with client generated packets.
Fig. 5. Packet size of server generated traffic over time. Note the periodic
cycles of different packet sizes corresponding to the progress of rounds in a
game.
The left side of figure 4 also illustrates the large degree of
similarity at various resolutions and the variation in service
rate over time. We can conclude that this is most likely due to
variation in interarrival time between packets. If we examine
the coefficient of variation for packet size and interarrival time
for all traces, shown in table 1, we see that the dispersion
associated with packet size is actually quite small while the
dispersion associated with interarrival time is significantly
larger.
TABLE 1. STATISTICAL MOMENTS FOR ALL TRACES OF CLIENT GENERATED
TRAFFIC.
Packet Size
(bytes)
Interarrival
Time (sec)
Standard
Deviation
(σ)
7.631
Mean
(µ)
62.235
Coefficient
of Variation
(σ/µ)
0.123
0.00966
0.0132
0.734
Server generated traffic
The server delivers UDP periodically to update the scene
displayed on the client. Depending on the client’s location
and actions occurring within view of the player, this packet
and be relatively large or small. Figure 5 illustrates the packet
Fig. 4. Multi-resolution illustration of service rate versus aggregate time series of
100, 32, 10, 3.2, 1, 0.32, and 0.1 seconds (from top). (Left side) Client generated
traffic for various resolutions. (Right side) Server generated traffic.
size of server generated packets over time. From examination
of this figure, we can see a definite periodicity associated with
the packet size. This corresponds to the rounds within the
AAO game. At the beginning of the round, the team is
gathered together and there is much information about
member’s movements and actions for the server to pass on to
the client. As team members disperse and eventually are
eliminated, the amount of information the server needs to pass
to the client diminishes. Eventually the round end ends when
all of one team is eliminated or the objectives are all achieved
and a new round begins.
The distribution of packet sizes for server generated traffic
is shown in figure 6. Examination of this figure reveals that
the server generates packet size with a much larger variation
and consequently a heavier tail than we saw with the client.
This also corresponds with the effect noted above associated
with the progress of rounds within the games.
TABLE 2. STATISTICAL MOMENTS FOR ALL TRACES OF SERVER GENERATED
TRAFFIC.
Packet Size
(bytes)
Interarrival
Time (sec)
Standard
Deviation
(σ)
104.164
Mean
(µ)
190.511
Coefficient
of Variation
(σ/µ)
0.547
0.0514
0.118
0.436
Finally, returning to figure 4, the right side of the graphic
illustrates the service rate of server generated packets at a
variety of resolutions. The graphic illustrates how the server
traffic is much less correlated than the client traffic.
Additionally, we can see how the variance decreases with
higher order time series (e.g. 100s/sample). There is still
some level of short-range dependent similarity that apparently
has contributions from variations in both packet size and
interarrival time. This is revealed to some extent by examining
the dispersion as shown in table 2.
Self-similarity analysis
A common technique for estimating the degree of selfsimilarity in a packet trace is by examining the variance of the
distribution for different order time series [9]. In this case, the
m
time series, xk , is defined as
xkm =
Fig. 6. Distribution of Packet sizes for server generated traffic.
The interarrival time of server generated packets is shown
in figure 7. Again a wider tail is observed than we saw with
the client generated traffic. This is further obfuscated by the
queuing effects of the Internet in general [8].
km
1
∑ xi
m i = km −( m −1)
(1)
where m is the order of the series and k is the discrete point in
time.
As discussed in [9], the Hurst parameter, H, is frequently
used as a measure of self-similarity in a random process. The
Hurst parameter can be related to a parameter, β, by
H = 1− β 2
(2)
where β is related to extent of correlation in the process. For a
self-similar process
log[var( xkm )] ∼ log[var( x)] − β log m .
m
(3)
Thus if we plot log[var( xk )] versus log m, a self-similar
process should yield a straight line with slope – β.
Fig. 7. Distribution of interarrival times for server generated traffic.
Fig. 8. Plot of logarithm of the time series variance versus the logarithm of the
order of the times series. Self-similarity is indicated by a straight line. This is
particularly in the client traffic process.
Figure 8 plots the aggregate time series variance of the
service rate for both client and server generated traffic versus
the time series order (m). Certainly, for the case of the client
(dashed line) we see a nearly flat line with a slope
approaching zero indicating strong long-range dependence.
Self-similarity in the server generated traffic is not so clearly
evident. There are regions where stronger self-similarity is
evident, however, in general the server traffic process can be
described at best short-range dependent. (H = 0.5).
2. Conclusion
An analysis of traffic associated with the Internet-based
gaming engine, Unreal Engine, was presented. This analysis
revealed that client generated traffic has strong, long-range
dependence and a high level of self-similarity. This is
apparently due to the nature of user input into the game
environment via player movement or other actions. On the
other hand, while still somewhat heavy-tailed, server
generated traffic did not appear as strongly correlated or selfsimilar, despite experiencing the effects of Internet transport.
Self-similar traffic behavior has the effect of forcing
network equipment manufacturers and architects to be more
conservative in their design. If this nature holds true for client
input to Internet-based MMOG and MMPW, this property
could have significant ramifications for future system
performance.
No source models were presented in this paper, however, it
is reasonable to assume the both traffic processes could be
extended to a heavy-tailed distribution such Pareto or Weibull.
Future research will examine this possibilities.
REFERENCES
[1] Gehorsam, R., “The coming revolution in massively
multiuser persistent worlds,” Entertainment Computing,
April, 2003. pp. 95 – 97.
[2] Plummer, A. “Pentagon looking at next generation of
online gaming technology,” Inside the Pentagon, Nov. 7,
2002.
[3] http://www.americasarmy.com/
[4] Wiltenburg, M., “More than playing games,”
Reuters/Christian Science Monitor, April 3, 2003.
[5] Bangun, R. A., Dutkiewicz, E., and Anido, G. J., “An
analysis of multi-player network games traffic,” Proc. of
the 1999 IEEE 3rd Workshop on Multimedia Sig. Proc.,
Copenhagen, Sept. 1999. pp. 3 – 8.
[6] Borella, M. S., “Source models of network game traffic,”
Proc. of Networld+Interop ’99 Engineers Conference,
May 1999..
[7] Bangun, R. A. and Dutkiewicz, E., “Modelling multiplayer games traffic,” Proc. of the Intl. Conf. on Info.
Tech.: Coding and Computing, 2000, Las Vegas, March
2000. pp. 228 – 233.
[8] Floyd, S. and Paxson, V., “Difficulties in simulating the
Internet,” IEEE/ACM Trans. on Networking, vol. 9, no. 4,
August 2001. pp. 392 - 403.
[9] Leland, W. E., Taqqu, M.S., Willinger, W., Wilson, D.V.,
“On the self-similar nature of Ethernet traffic (extended
version),” IEEE/ACM Trans. on Networking, vol. 2, no.
1, Feb 1994. pp. 1 – 15.