A Survey of First Person Shooter Gaming Traffic

on the Internet
Saurabh Ratti, Behnoosh Hariri, Shervin Shirmohammadi
Distributed Collaborative Virtual Environment Research Laboratory, University of Ottawa, Canada
{sratti | bhariri | shervin}@discover.uottawa.ca

There is no doubt that online games will become major contributors to Internet traffic. The NPD Group reports that almost one
third of the total U.S. population plays online games, and World of Warcraft alone has over 11.5 million subscribers with
approximately half a million playing online at a time [1]. As online games become increasingly popular and significant
contributors to Internet traffic, practitioners must look to measure and understand game traffic in order to provision for it.
Despite its significant implications for the Internet, no general framework has been presented to validate various and sometimes
contradicting game traffic models. As such, practitioners today must find and study dozens of reports and papers, some with
conflicting measurements, to be able to understand traffic characteristics and use it in their systems. In this survey, we cover the
most representative First Person Shooter (FPS) game traffic as a one-stop shop for practitioners.

The FPS game genre is one of the biggest and fastest growing video game genres, being the most
attractive to publishers in terms of revenues[2]. FPS games allow players to move about and
interact with each other and do battles in real time in a virtual environment. In this article we
provide a survey on FSP traffic traces. Our aim is to give background on the shared networking
architecture currently in use and draw a general process taken for measuring and modeling game
traffic from field research. With this we present the relative characteristics of datasets analyzed
in research and validate various, sometimes contradicting, game session traffic models derived
from said datasets. We do so in a fashion that presents game traffic with respect to the evolution
in game engine design, in the hope that this leads insight into future traffic. Let us begin by
providing an overview of game engine characteristics, parameters of interest, and networking
protocols.

NETWORKING COMMONALITIES IN GAMES

Architecturally, the majority of FPS engines employ a shared networking model in terms of
responsibility distribution and behaviours. There are instances of engine “families”, as
developers attempt to address shortcomings of a contemporary engine in the subsequent
iteration, or generation, in order to produce a more favourable playing experience. Though not
all engines are related in this manner, there is still also a general evolution in engine design, as
lessons are learnt from the successes and failures of others. Table 1 provides a list of popular
FPS games included in this survey.

Table 1: FPS Game Summary

Game Released Primary/Base Engine
Quake 1996 Quake
QuakeWorld 1996 QuakeWorld (modified Quake engine)
Quake II 1997 id Tech 2 (QuakeWorld successor)
Half-Life 1998 GoldSrc (heavily modified QuakeWorld engine)
Unreal Tournament 1999 Unreal Engine 1.0
Quake III Arena 1999 id Tech 3
Counter-Strike (Half-Life mod) 1999 GoldSrc
Day of Defeat (Half-Life mod) 2000 GoldSrc
Halo: Combat Evolved (Halo:CE) 2001 Halo Engine
Medal of Honor: Allied Assault (MOH:AA) 2002 id Tech 3 (with modified SDK)
Unreal Tournament 2003 (UT2k3) 2002 Unreal Engine 2.0
Wolfenstein: Enemy Territory (ET) 2003 id Tech 3 (modified)
 Unreal Tournament 2004 (UT2k4) 2004 Unreal Engine 2.5
Halo 2 2004 Halo 2 Engine
Half-Life 2 2004 Source (GoldSrc successor)
Counter-Strike Source (CS:Source) 2004 Source
Quake 4 2005 id Tech 4

All FPS use a client-server networking model, where the game server can be either a dedicated
host or run by one of the client machines that participate in the shared simulation. During game
play, the server carries out the “master” version of the shared simulation experienced by the
players. The server is the final authority on the transpirations of the game world, in order to
synchronise all clients and prevent certain types of client-side cheating. All client simulations are
kept up-to-date during a match by server update packets that are sent out at regular intervals. The
major features of these update packets are a game timestamp and information on all the other
entities (map objects and other players) of interest to the client being updated. The size of these
update packets could be highly variable due to the number of players and objects in the game,
and the various forms of compression applied to packets.

It is of note that console FPS games can allow “hotseat multiplayer”, where multiple players play
on a single host, something rather rare on PCs. This is of note when analysing console traffic
characteristics as server-to-client updates, and vice versa, can be aggregated.

A client‟s reliance on the server heavily depends on the maturity of client‟s engine. Early engines
are conceptually nothing more than thin rendering terminals; later generations include client-side
simulation to parallel the server‟s simulation, with divergences corrected subtlety for smooth
game play. Packets sent to the server from clients primarily consist of client “commands”. These
commands generally contain a client ID, packet sequence number, information on player‟s
current velocity, field of vision and indications of specific active inputs; this last would include
change of active weapon and its firing.

Update rates of both server and clients are often made configurable and though default values
tend to be kept, it is possible to optimize for players‟ last mile links. The majority of FPS games
prefer to use UDP as the transport protocol on top of the IP networking protocol. The fast game
pace means a constantly changing world where late or out-of-order updates are obsolete. The
simpler and more aggressive behaviour of UDP makes it favourable over TCP and its increased
overhead. Authentication to a game; however, may be done via TCP for reliability.

Network traffic generated by FPS games can be categorized into 3 basic groups:

1. Server discovery: In order to play, clients must find active game servers. This category
encompasses the traffic generated by clients‟ search and the ensuing connections to the servers.
This category is a constant background load on a network which is driven by 24-hour human
cycles[t.1]. Many works analyse the nature and effects of this traffic type, but are not within
our current scope.
2. Game initialization phase: In-between matches, all participating clients must be updated by
the server on the upcoming match with map, player and avatar data. As game initialization
traffic tends to be less sensitive to delay, jitter and packet loss, its needs can be accommodated
by designing for the following category.
 3. Game session phase: Encompasses the messages between client(s) and server during an
active match. Poor network performance for this traffic, beyond certain established thresholds,
directly affects playability. As it has the highest performance demands of the three, the focus of
this survey is on this traffic type.
TRAFFIC MEASUREMENT METHODOLOGY AND ANALYSIS

In game traffic measurement and analysis, there are three basic steps to be followed: data
capture; data scrubbing; analysis and modeling. Each of these steps can be carried out with
different parameters and if they are not documented, correlating separate analyses on the same
dataset can be non-trivial. Thus the value of a trace and its analysis is affected by how many of
these parameters are easily obtained or deduced.
DATA CAPTURE

Capturing larger and longer datasets, or “traces”, is preferred when long term characteristics are
of interest (e.g. player session lengths, player arrival patterns, long term bandwidth usage).
Smaller, single match traces can be sufficient when the focus is solely on the packet
characteristics for game sessions. During data capture, the following parameters can affect the
end traffic characteristics:

1. Game version – While major overhauls may warrant a new identifier (i.e. Quake to
QuakeWorld), smaller patches may contain updates/changes/optimizations to the network
related code that could change the game behaviour with respect to network traffic.
2. Technical Environment – Use of a dedicated or non-dedicated server affects the
performance of all participants. Client/server capabilities, as well as the specific network
technology, also have an impact.
3. Game configuration – Games tend to have configurable network performance, as default
configurations may not be optimal for the available network resources. These configurations
directly relate to characteristics seen in traffic and the resulting models.
4. Match configuration – Several match related parameters can also affect gaming traffic, such
as the selected map and the number of players.

Table 2 summarizes traffic datasets referred to in this survey. A void entry indicates particular
information that is either not reported or cannot be confidently deduced.
 Table 2: Summary of Network Trace Datasets
Measurement Capture
T# Game Ver. Game Config. Match Config. Trace Size Src.
Environment Mechanism
Non-dedicated
1 Quake 4-6 Players Tcpdump♦ 2 traces: 20:23 min [t.2]
servers♦╬
2 QuakeWorld ╬ 10-13 players tcpdump♦ [t.3]
3 QuakeWorld
Internet 645x10^6 packets
Unreal HW Cards♦ [t.4]
4 servers╬ over several months
Tournament
10 traces 5-10 min
5 Quake II ♦╬ 2 players Shomiti ATS [t.5]
each
8-30 players,
6 Counter-Strike ╬ 6.5 hours [t.6]
30-90 minutes
7 Counter-Strike 1.3 ╬ 3 players;▲ Commview♦ [t.7]
Dedicated
8 Half-Life 3-7 players;▲ Pkthisto 2 months, 15 games [t.8]
server ╬
14 players tcpdump,
9 Halo:CE 3 Xboxes ╬ [t.9]
maximum pkthisto♦
Dedicated
10 Quake III 2-8 players;▲ Pkthisto 2 months [t.10]
server╬
Dedicated
11 Counter-Strike 32 players max tcpdump 1 month [t.11]
Internet Server
Client and NetGame
12 Quake III 2-4 players;▲ [t.12]
server♦ ╬ Sniffer
Anti-cheat &
Dedicated
team killing 1 week, 5x108
13 Counter-Strike 1.3 Internet 22 players max
deterrent packets
Server♦╬
modules
[t.1]
14 Day of Defeat
Medal of Honor: Dedicated
15 3 hour trace
AA Internet Server
16 UT2k3
Unreal
17 2 or 4 players [t.13]
Tournament
3-11 players (1- tcpdump, 9 games; 6 minutes
18 Halo 2 4 Xboxes╬ [t.14]
4 per Xbox) pkthisto♦ each
19 Quake III
20 Wolfenstein:ET
21 Counter-Strike
Counter-Strike
23 ◙ ◙ ◙ 2-9 players◙▲ tcpdump♦◙ ◙ [t.15]
Source
22 Half-Life
24 Half-Life 2
25 Quake 4
Patch Dedicated 130 games, 10 min
26 UT2k4 wireshark [t.16]
3369 server╬ each; 7x107 packets
The following symbols indicate that the information specified by the label is available in the referred source.
◙ Extensive documentation. ╬ Network description. ♦ Hardware/software specifications. ▲ Specific map usage.

Traces:
[t.1] W. Feng , F. Chang , W. Feng and J. Walpole, “A traffic characterization of popular on-line games,” IEEE/ACM Transactions on
Networking, vol.13, no.3, pp.488-500, June 2005.
[t.2] M. S. Borella, “Source models of network game traffic,” Computer Communications, vol. 23, no. 4, pp. 403-410, Feb. 2000.
[t.3] R.A Bangun, E. Dutkiewicz and G. J. Anido, “An analysis of multi-player network games traffic,” in Proceedings of MMSP, 1999, pp. 3-8.
[t.4] S. Joyce, “Traffic on the Internet – Report,” October 2000. [Online]. Available: http://atm.cs.waikato.ac.nz/pubs/14/pdf/sarah-420.pdf.
[Last Accessed: October 31, 2009].
[t.5] J. Lakkakorpi, A. Heiner and J. Ruutu, “Measurement and characterization of Internet gaming traffic,” Research Seminar on Networking,
Helsinki University of Technology, Networking Laboratory, Espoo, Finland, Feb. 2002.
[t.6] J. Färber, “Network game traffic modelling,” in Proceedings of Netgames, April 2002, pp. 53–57.
[t.7] M. Claypool, D. LaPoint and J. Winslow, "Network analysis of Counter-Strike and Starcraft," in Proceedings of IPCCC, April 2003, pp.
261-268.
[t.8] T. Lang, G. J. Armitage, P. A. Branch and H. Choo “A synthetic traffic model for Half-Life,” presented at ATNAC, Melbourne, Australia,
2003.
[t.9] T. Lang, G. J. Armitage, “A Ns2 model for the Xbox system link game Halo,” presented at ATNAC, Melbourne, Australia, 2003.
[t.10] T. Lang, P. A. Branch, and G. J. Armitage, “A synthetic model for Quake3 traffic,” in Proceedings of ACE, June 2004, pp. 233-238.
[t.11] J. Färber,” Traffic modeling for fast action network games,” Multimedia Tools and Applications, vol. 23, pp. 31-46, May 2004.
[t.12] H. Park , T. Kim and S. Kim, “Network traffic analysis and modeling for games,” in Lecture Notes in Computer Science, vol. 3828/2005,
 Heidelberg, Berlin: Springer, 2005, pp. 1056-1065.
[t.13] P. A. Branch and G. J. Armitage, "Towards a general model of first person shooter game traffic," Centre for Advanced Internet
Architectures, Melbourne, Australia, CAIA Technical Report 050928A, September 2005.
[t.14] S. Zander and G. Armitage, "A traffic model for the Xbox game Halo 2," in Proceedings of NOSSDAV, October 2005, pp. 13-18.
[t.15] Centre for Advanced Internet Architectures, "Simulating online network games (SONG)," [Online]. Available:
http://caia.swin.edu.au/sitcrc. [Last Accessed: October 30, 2009].
[t.16] C. Hübsch, "Analyzing Unreal Tournament 2004 network traffic characteristics," in CGAT'08, Singapore, April 2008.

As can be seen, many works do not fully report their capture details. An exception to this is
SONG[t.15], which is a well documented, and publicly available, database of FPS traffic traces
used in several recent works[3][4][5][6][7].
DATA SCRUBBING

After capture, traces are “scrubbed” to remove packets of non-interest and indentify flows
between server and clients. In addition, the data may be further massaged for analysis, creating
further parameters:

1. Analyzed Payload Level – The transport and network layer headers provide useful
information in tracing and understanding the network traffic. The specific packet payload
analyzed may, or may not, include these headers.
2. Inclusion of game initialization phase –This phase‟s footprint differs from that of the
session phase. If not accounted for, the analysis of traffic that includes this with the session
phase will have an altered statistical fingerprint.
ANALYSIS AND MODELING

Traffic characteristics are then extracted, tabulated, plotted and analyzed. At this point, the effect
of measurement resolution and “binning” can be considered. If values are aggregated into “bins”
to manage large data sets, final results may become slightly skewed from those with finer
resolution. Within the works surveyed here, the standard units given in Table 3 tend be observed,
except for [t.4] and [t.7] who give measured packet IAT in seconds with 2 significant digits. [t.3]
presents packet IAT CDF plots in 10ms bins, and [6] bins packet lengths together when creating
transition matrices for their Markov model.

Table 3: Standard Measurement Units

Characteristic Standard Unit Value
Packet Inter-arrival Time (IAT) Milliseconds (ms)
Packet length Bytes (B)
Bandwidth / Data Rate Kilobits per second (kbps)
Packet Rate Packets per second (pps/PPS)

In game traffic, the most heavily analyzed parameters are packet size and packet IAT, which is
the time between sending subsequent packets1.

To find statistical models for traffic characteristics, outliers from the data sets are removed in
order to focus on dominant values. Statistical software packages, employing various techniques
such as the maximum likelihood estimation (MLE), can be used to determine traffic distribution.
Some practitioners create what can be thought of as “second-order” models, as in [t.13]; instead

1
Inter-arrival, instead of inter-send, is used as packets departing from a host are seen as “arriving” on the wire[t.2].
of directly modeling a traffic characteristic, they model the logic driving it, producing a flexible
model with intuitive parameters. Ideally, models are run through goodness-of-fit tests against
empirical data, in order to quantify correctness and re-model if necessary. The Q-Q plot is a
popular choice, as are K-S test and λ2 measure. [t.2] states however, that the K-S test is said to be
biased against large or “messy” datasets, as well as those that exhibit significant autocorrelation
which is shown to apply in the case of gaming traffic[6].

Table 4 summarizes the methodology taken by our survey sources for traffic measurements, and
also lists other characteristics presented, but not modeled. The third column „T#‟ is an index
number referring to the trace dataset description that can be found in Table 2.
 Table 4: Summary of Modeling Methodology for Survey Sources (in order of source year)
Pay- Session Characteristics‟ Plots Validation Other Characteristics
Source Game T#
load Only Modeled Modeled Performed Analyzed or Presented
Q-Q plot, λ2
Mean data rate,
Borella[t.2] Quake 1 Game PIAT, PL PDF measure, extreme
autocorrelation function
upper tails checked
Bangun[t.3] QuakeWorld 2 Yes PIAT (CDF), PL (CDF)
QuakeWorld 3
Joyce[t.4] Unreal IP No PIAT (PDF), PL (PDF)
4
Tournament
Q-Q plot, λ2
Lakkakorpi Mean data rate,
Quake II 5 UDP PIAT, PL PDF measure, extreme
[t.5] autocorrelation function
upper tails checked
Färber[t.6] Counter-Strike 6 No PIAT, PL PDF, CCDF DROGT, PROT
PIAT (CDF), PL (CDF),
Claypool[t.7] Counter-Strike 7 No
data rate over time
Lang[t.8] Half-Life 8 IP No PIAT, PL PDF Q-Q plot DROGT, PROT
PDF, PL vs.
Lang[t.9] Halo:CE 9 IP PIAT, PL DROGT, PROT
number of players
Lang[t.10] Quake III 10 IP No PIAT, PL PDF Q-Q plot DROGT, PROT
Mean PPS vs. number of
Färber[t.11] Counter-Strike 11 No PIAT, PL PDF, CCDF players, mean data rate vs.
number of players
Data and packet rates for
Park[t.12] Quake III 12 Yes PIAT, PL PDF Q-Q plot, K-S test
varying in-game behaviours
Player session DROGT, PROT, packet rate
Counter-Strike 13 PDF
duration power plot, data rate vs.
Day of Defeat 14 number of players, PL
MOH:AA 15 (PDF, CDF), player failure
Feng[t.1]
rate over time, mean PPS,
mean PL, bandwidth vs.
UT2k3 16 number of players, various
trace statistics
Quake III 10
Branch[t.13] Unreal Yes PIAT, PL PDF K-S Test
17
Tournament
Q-Q plot, λ2
PDF; avg.
PIAT, PL; client- measure, extreme
Zander[t.14] Halo 2 18 IP bandwidth vs.
server bandwidth upper tails checked;
number of clients
error bars
Quake III 19
Wolfenstein: ET 20
Half-Life 21 Server-to-Client Q-Q plot, λ2
Cricenti[3] IP Yes PMF
Counter-Strike 22 PL measure
Half-Life 2 23
CS:Source 24
Q-Q plot, variance ARMA(1,1) 'innovations'
Cricenti[4] Quake 4 25 Packet length PDF
test and Laplace for PL (PDF)
Quake III 19
Wolfenstein: ET 20
Branch[5]
Half-Life 21 Server-to-Client
Branch[6] IP Yes PMF
Counter-Strike 22 PL
Branch[7]
Half-Life 2 23
CS:Source 24
Hübsch Packet rate over time, PIAT,
UT2k4 26 Yes
[t.16] PL

PIAT: Packet IAT. PL: Packet Length PROT: Packet Rate Over Time DROGT: Data Rate Over Game Time

EMPIRICAL INTERNET GAMING TRAFFIC ANALYSIS

In this section, we present and discuss the various models and analyses made for the popular
traffic characteristics: packet IATs and packet size. These are popular as they provide a base that
leads to packet rates, data rates and their relationships to various other parameters. We also
examine apparent discrepancies from different reports regarding the same engine, and validate
observed patterns and values with the applicable engine design logic.

PACKET INTER ARRIVAL TIMES

Server Packet IAT
Quake servers attempt to update clients every 50 milliseconds (20 updates per second)
corresponding to the mean 49.66ms server IAT measured on 133MHz PC in [t.2]. Quake is very
hardware dependent however, as a 233MHz PC sends updates every 26.58ms on average[t.2].

QuakeWorld updated Quake for better Internet play, reducing server-side queuing related latency
by sending an update in response to an incoming client command. This leads to irregular server
IATs, such as the 10ms-80ms range of IATs measured in [t.4] and the dominating 10ms IATs in
[t.3].

id Tech II and id Tech III, QuakeWorld‟s successors, return to configurable, fixed-interval

update cycles. id Tech II defaults to one-tenth of a second[8], corresponding to the measured
mean 102ms in [t.5]. Several sources have measured id Tech III (Quake III & MOH:AA) server
packet IATs to be densely distributed around 50ms[t.1][t.10][t.12][t.13]. As clients are updated
in batches, the IAT for (100*(L-1)/L)% of packets is close to 0ms, and is close to 50ms for the
remaining percentage (L denotes the number of active clients)[t.10].

GoldSrc also attempts to send regular updates to each client, with the rate dependant on the game
configuration. Half-Life servers send updates every 60ms for most maps[t.8], while Counter-
Strike shows a high-frequency component at 20Hz (50ms)[t.1][t.6][t.11]. Other frequency
components seen in [t.1] may be attributed to game initialization phases. The 50ms server update
rate is also observed for Day of Defeat[t.1].

Unreal Tournament‟s server IAT distribution has a majority component of 60ms, with a much
smaller peak at 240ms[t.4]; this smaller peak is attributed to some post-client disconnection
packets[t.4]. Its successor, UT:2k3 exhibits a larger update period of 100ms[t.1]. The more
contemporary UT:2k4 updates clients more regularly, every 56ms, during game activity[t.16]; a
period of 280ms is used in the absence of game action[t.16].

The batch update property seen in id Tech III also applies to Halo:CE[t.9] and Halo 2[t.14], but
with a 40ms IAT for their remaining percentage.

Client Packet IAT

Quake client performance, like the server, varies with hardware performance; calculations show
a close relationship between processor speed and packet generation rate[t.2].

As in Quake, QuakeWorld clients send a message to the server for every move order input that
they process, also relative to the speed of the host. In [t.4], clients had large peak IATs at 14ms
and 27ms, and lower peaks at 40ms and 53ms, corroborating the findings in [t.2]. Though [t.3]
showed a range of IATs between 20ms and 50ms, it can be attributed to the BYOC (Bring Your
Own Computer) environment, and that host machines were connected to the 10BaseT Ethernet
LAN backbone via a dumb hub rather than a higher level networking device. Given these
conditions and the 10ms timing resolution of the findings, the value ranges are not
contradictory[t.4].

For id Tech II, the mean IAT is found to be 40.6ms with the standard deviation of 22.5ms in
[t.5].

A client‟s packet IAT is still affected by the host machine‟s processing capability, though they
attempt to communicate regularly. id Tech III measurements reported in [t.10] show that fast
clients have IAT of 10.75ms while slower machines have larger IATs. With regard to in-game
behaviours, higher activity results in update packets being sent out at a greater rate, as reflected
in [t.12] which reports a mean IAT of 12.7ms for shooting clients, and increasingly larger values
for moving, normal and no-play clients. Game maps also have impact, as some have regular
transmission intervals, while others send more randomly[t.10]. These relationships might
therefore cause measurement conflicts if not equalized between traces. [t.13] measured the client
packet IAT to be approximately 20ms, but it should be noted that a client‟s update rate is
configurable by either the client or the server.

GoldSrc engine clients have regular updates, with mean packet IAT approximated around 50ms
[t.11] and 40ms [t.6] in Counter-Strike. For Half-Life, the packet transmissions from different
clients to the server are very dependent on the graphic rendering tool. OpenGL clients transmit
packets very periodically in 33ms and 50ms intervals, while clients using software rendering
transmit one packet every 41ms[t.8].

Unreal Tournament is observed to have clients transmit regularly every 25ms[t.4]. Hardware
dependency is seen in the later UT:2k4, where client IATs are very closely tied to the game
frame rate; the frame rate in turn is dependent on many factors[t.16].

Halo:CE and Halo 2 clients send commands every 40ms[t.9][t.14]. Halo:CE has some
distinguishing features however, as analysis shows that hardware performance shifts the 40ms
value, and that clients send a packet every 210ms in a “secondary stream” to the server[t.9].

PACKET LENGTH

Server Packet Length

In Quake, all packet data is uncompressed. Packets have a 9B application header to hold message
reliability type, length and sequence identifier[9]. The overall length of the packet is variable, not
due to compression but due to Quake‟s occlusion culling technique, Potentially Visible Sets
(PVS), which changes the amount of data sent to a client depending on the client‟s position in the
map. This variability is reflected in [t.2] where mean packet sizes of 109.76B and 77.43B have
considerable standard deviations of 42.61B and 29.44B respectively.

QuakeWorld adds to the above the concept of delta compression; i.e., only data changed from the
last acknowledged packet is sent to clients in updates. QuakeWorld‟s packet variability is
confirmed in [t.4] with a majority range of 20B to 70B, and in [t.3] who shows a packet sizes
between 25B to 300B. The upper limit discrepancy can be attributed to the unknown number of
players in [t.4], versus the 10 to 12 players in [t.3].
id Tech II also uses delta compression, resulting in the hefty standard deviation of 52.5B that
accompanies a 77.9B mean packet size (including the UDP header)[t.5].

Packet compression is a popular as a form of bandwidth conservation, and can be found in

contemporary engines. Due to this, server packet lengths in later engines are often modeled as
various distributions, in order to fit the range and envelope of values measured. Researchers
looking at the server packet length distributions for different game sessions do find that these
distributions are affected by other factors. [t.12] shows the effect on packet size from differing
player behaviours. [t.10] finds that different maps have slight effect, but the number of players
has a profoundly linear effect on packet size. In fact, the addition of one player results in an
overall increase in packet length by 12B or 13B in id Tech III.

This holds for GoldSrc as well, as server packet size for Counter-Strike is measured to have a
wide distribution [t.1] and is linearly dependant on the number of clients. These packets have a
mean size of 50.4B, plus 6.15B per additional client (excluding UDP header)[t.11]. The 90B
mean measured for 8 players in [t.7] also matches with this formula. In general the packet
lengths also have a wide spread and range from 60B to 300B depending on the map[25].

The general relationship between server packet size and number of players is so strong that it has
prompted researchers to produce several works on modeling game sessions for N players with
various methods. [t.13] creates a general model for packet length the for id Tech III and Unreal
1.0 engines; the model is based on convolutions of continuous random variables to create a PDF
for the sum of said variables. The following work, [5], extends this technique in order to
extrapolate game sessions models for any number of players. Similar extrapolation is
accomplished using ARMA(1,1) time-series modeling in [7] (extending [3]), and also using
Markov models in [6]. [3], [5], [6] and [7] apply their analyses on the GoldSrc, Source and id
Tech III engines.

Unreal Tournament shows server packet sizes to range from 40B to 150B, with dips in size that
seen that match up to client-side activity[t.4]. [t.16]finds that the number of players, as well as
their activity levels, have an effect on UT2k4 packet lengths.

Halo server packet sizes linearly increase with the number of players in the game[t.9]. Halo 2
shows similar correlation, but is not strong enough to form a linear relationship[t.14]. The
characteristic server packet sizes in Halo 2 have the unique pattern of being 4B multiples and
spaced 8B apart, without occurrences of intermediate values[t.14].

Client Packet Length

As clients only report their own updates to the server, clients‟ packets size have a limited range,
and only depend on the players actions. Quake client commands are 24B in length for both
packet application header and movement values[8], empirically corroborated by measurements
in [t.2]. The deviation seen around the average value is caused by the generation of other, but
rarely sent, message types.

In QuakeWorld, the application payload is 45B of data, but is not fixed at that size due to delta
compression. This is supported by in [t.4] with 20B to 40B, and [t.3] with 30B to 45B. The near
upper limit confirms the payload size, while the lower limits indicates compression. This is
similar to id Tech II, as [t.5] models packet size as a seven way deterministic split distribution
between 36B and 51B.

For idTech III, [t.12] shows that higher activity equates to a constantly changing player state,
which means delta compression is less effective; this produces a range between 50B and
70B[t.10][t.12].

Counter-Strike client packets have a narrow distribution with the mean size of 42B[t.1][t.11] to
52B[t.6]. In Half-Life, the client-to-server packets have a limited range of 60B to 90B and are
independent of computer hardware, number of players, or maps[t.8].

Unreal Tournament packet sizes range between 50B and 65B[t.4]. Dips in packet size observed
in the trace are attributed to player death and re-spawn, as their activity level is minimal[t.4].
UT2k4 follows this trend, as [t.16] presents analysis relating client payload size to a player‟s
activity level, as well as to their overall PPS rate.

Halo:CE and Halo 2 client packet lengths are found to be linearly related to the number of
players on a given console[t.9][t.14], stemming from console “hotseat multiplayer”. Halo:CE
clients‟ secondary stream packets are consistently 72B in length[t.9].

TRAFFIC CHARACTERISTIC & MODELING SUMMARY

Given the above analysis, game traffic over a network can generally be modeled by aggregating
independent traffic streams from each client to the server, as well as a traffic stream from the
server to the clients, assuming that clients behave independently and client traffic is independent
of the server traffic. For most games, traffic in the client to server direction usually consists of
small IP packets whose size distribution is independent of the number of players on a given
server. On the other hand, traffic in the server to client direction usually shows distinct variation
as the number of players increases. Table 5 tabulates the models for these traffic characteristics,
specific to each game and grouped by engine “family”.
 Table 5: Summary of Game Engine Traffic Characteristics
Server Client
Games Burst IAT (ms) (per
Packet size (Bytes) IAT (ms) Packet size (Bytes)
(Engine) client)

Variable : Variable :
≈50 Number of players (N) Client Hardware ≈24
Inter-entity visibility Inter-entity visibility
Quake
Extreme(20.63, 4.39)
Extreme(89.92, 34.84): N=4 Extreme(23.6, 5.2)
Deterministic(60) Extreme(36.38, 8.01) Deterministic(24)
Extreme(65.58, 19.12): N=5 Extreme(15.89, 2.98)
Extreme(30.26, 6.3)
Variable :
Irregular: sent in
Number of players Variable :
response to client Variable : delta compression
Inter-entity visibility Client Hardware
command
QuakeWorld Delta Compression
(14, 27) : main peaks
Extreme(peaks at 26,14) Min(20) Max(45)
(40,53) : smaller peaks

Variable :
Number of players Variable :
≈100 ≈45
Inter-entity visibility Client Hardware
Delta Compression
Quake II
(id Tech II) Lower 4.8%, x < 60: Lower 27.6%, x < 55: Lower 4.5%, x < 18: Deterministic:
Extreme(58.2, 7.47) Extreme(46.7, 4.39); Extreme (6.57, 0.517) 10.6%: 28, 26.4%: 34,
6.26%: 36, 13.9%: 37,
Upper 95.2%, x ≥ 60: Upper 72.4%, x ≥ 55: Upper 95.5%, x ≥ 18: 4.95%: 38, 16.3%: 40,
Normal(100, 17.7) Extreme (79.7, 11.3) Extreme(37.9, 7.22) 21.5%: 43
Variable : Variable :
Number of players Client Hardware
≈50 Inter-entity visibility Game setting [50 70]
Delta Compression Current map
Quake III
[50 400] [10 30]: 10.75
(id Tech III)
Lognormal(79.3,0.24):base Faster graphic card
exponential(13) : for each additional pair 60% : Spike(10.75)
of players 40%: exp(4.29)
Gamma(50) Normal(64.15, 3.2)
ARMA(1,1), Markov and convolution Slower graphic cards
based models; 16% : Spike(10.75)
(N-player extrapolation capable) 84%: :exp(5.85)

ARMA(1,1), Markov and convolution

Wolfenstein:ET
based models;
(id Tech III)
(N-player extrapolation capable)

Quake 4
ARMA(1, 1) model
(id Tech 4)

Map dependant: variable :

Variable :
50,70 OPEN-GL: 33 -50 [60 90]
map
60 Other rendering : 41
Lognormal(109, 0.24)
Half Life Lognormal(130, 0.37)
(GoldSrc) Lognormal(154, 0.25)
Lognormal (72,6.9)
Deterministic(60) Lognormal(203, 0.31) Spikes
ARMA(1,1), Markov and convolution
based models;
(N-player extrapolation capable)

Counter-Strike Variable :
≈60 ≈50 ≈40
(GoldSrc) Number of players (N)
 Extreme(34.5+4.2N, 9+3N)

Extreme(50,5.7)
Extreme(55,6) Extreme(60, 1.1)
Extreme(41,6) [20 100]
ARMA(1,1), Markov and convolution
based models;
(N-player extrapolation capable)

Half-Life 2 ARMA(1,1), Markov and convolution

CS: Source based models;
(Source) (N-player extrapolation capable)

Unreal
Tournament Deterministic(60) [40 150] Deterministic(25) [50 65]
(Unreal 1.0)

Deterministic(56) Variable: Variable :

Unreal
Number of players & Activity Client Hardware Variable:
Tournament 2004
During inactivity: Packet rate Frame Rate
(Unreal 2.5)
Alternating(280, 56) During Inactivity: (20) & (45) Player activity and interaction
Deterministic &
Variable: ≈40, ±shift from
Variable : Variable:
≈40 hardware dependency
Number of players (N) Number of players on
Fixed: 210
console (C)
Halo:CE

Packet 1: (40+shift) Packet 1: (30C + 80)

Deterministic(40) 30N + 100
Packet 2: 210 Packet 2: Deterministic(72)

Variable : 19.04C + 55.12

≈40 ≈40
Number of players (N) (C players on client console)

Round to nearest 8B packet size:

Extreme(126.9, 20.4): N=3
Halo 2 Extreme(146.7, 22.3): N=4
Extreme(71.2, 1.9): C=1
Extreme(167.6, 25.1): N=5
Extreme(86.9, 5.1): C=2
Extreme(180.5, 21.2): N=6
Extreme(39.7, 1.9) Normal(40, 1) Extreme(111.5, 7.7): C=3
Extreme(241.3, 21.6): N=7
Extreme(127.7, 8.2): C=4
Extreme(236.4, 25.8): N=8
Extreme(226.8, 26.2): N=9
Extreme(249.8, 28.9): N=10
Extreme(271.0, 33.0): N=11

CONCLUSION

In this article, we surveyed various FPS game traffic analyses reported in literature, and
explained the impact of certain parameters that would lead to different traffic characteristics and
measurement results. Game specific networking logic, update packet structure and choice of
bandwidth saving techniques are the biggest factors in distinguishing games‟ traffic from one
another.

Correlating separate findings on the same game/engine is possible, but is made increasingly
difficult if game, environment and measurement parameters are not documented alongside. In
addition to this, practitioners looking to use these models in simulation will want to emulate their
environment as much as possible. If information regarding a model‟s origin is unavailable,
proximity to a given reality cannot be quantified and the model is not of practical use. Thus the
validity of any given traffic trace, as well as the analyses and results derived from it, depends on
how thoroughly it is documented. We therefore recommend that traces be reported with a greater
number of known parameters, as it makes them more useful and easier to work with. Without
properly documenting the related parameters, researchers cannot confidently account for
discrepancies, correlate findings or validate results.

It is also interesting to note that the described shared networking model is highly applicable to
both older and newer games surveyed here. As the engines of these games are popular and
influential, it follows that the shared networking model is also applicable to many other
contemporary FPS games. This is evidenced by a current trend in recent works where a flexible
model, sometime dependent on empirically derived values, are applied to an array of FPS games.
This trend of generalized modeling will be of use until the next revolution in game networking
architecture.
 REFERENCES
[1] S. Shirmohammadi and M. Claypool, “Massively multiplayer online gaming systems and applications,” Multimedia Tools and
Applications, Springer, vol. 45, no. 1, 2009, pp. 1-5.
[2] F. Cifaldi, “Analysts: FPS 'Most Attractive' Genre for Publishers,” GamaSutra, February 2006. [Online]. Available:
http://www.gamasutra.com/php-bin/news_index.php?story=8241. [Last Accessed: 2 November, 2009].
[3] A. L. Cricenti, P. A. Branch and G. J. Armitage, "Time-series modelling of server to client IP packet length in first person shooter
games," in Proceedings of 15th IEEE International Conference on Networks, November 2007, pp. 507-512.
[4] A. L. Cricenti and P. A. Branch, "ARMA(1,1) modeling of Quake4 server to client game traffic," in Proceedings of Netgames,
September 2007, pp. 70-74.
[5] P. A. Branch and G. J. Armitage, "Extrapolating server to client IP traffic from empirical measurements of first person shooter
games," in Proceedings of NOSSDAV, October 2006, pp. 24.
[6] P. A. Branch, A. L. Cricenti and G. J. Armitage, "A Markov model of server to client IP traffic in first person shooter games," in
Proceedings of ICC, May 2008, pp. 5715-5720.
[7] P. A. Branch, A. L. Cricenti and G. J. Armitage, "An ARMA(1,1) prediction model of first person shooter game traffic," in
Proceedings of MMSP, October 2008, pp. 736-741.
[8] T. Ferguson, “Quake II network protocol specs,” December 1998. [Online]. Available:
http://www.csse.monash.edu.au/~timf/bottim/q2net/q2network-0.03.html. [Last Accessed: October 11, 2008].
[9] O. Montanuy, “Quake documentation version 3.4,” August 1996. [Online]. Available:
http://www.gamers.org/dEngine/quake/spec/quake-spec34/. [Last Accessed: 30 October, 2009].