Jose Saldana, Mirko Suznjevic, Luis Sequeira, Julian Fernandez-Navajas, Maja Matijasevic, Jose Ruiz-Mas, "The Effect of TCP Variants on the Coexistence of MMORPG and Best-Effort Traffic," IEEE ICCCN 2012, 8th International Workshop on Networking Issues in Multimedia Entertainment (NIME'12), Munich, Germany, July 30, 2012. ISBN: 978-1-4673-1543-2.

1. NIME 2012, Munich, 30th July 2012
The Effect of TCP Variants on the Coexistence
of MMORPG and Best-Effort Traffic
Jose Saldana1
Mirko Suznjevic2
Luis Sequeira1
Julián Fernández-Navajas1
Maja Matijasevic2
José Ruiz-Mas1
1 Communication Technologies
Group (GTC)
Aragon Inst. of Engineering Research (I3A)
University of Zaragoza
2 University
of Zagreb. Faculty of Electrical
Engineering and Computing

2. NIME 2012, Munich, 30th July 2012
Index
1.
2.
3.
4.
5.
Introduction
Related Works
Test Methodology
Results
Conclusions

3. NIME 2012, Munich, 30th July 2012
Index
1.
2.
3.
4.
5.
Introduction
Related Works
Test Methodology
Results
Conclusions

4. NIME 2012, Munich, 30th July 2012
Introduction
 Growing popularity of online games: number
of titles, and number of players growing,
especially in Asia
 MMORPG (Massive Multiplayer Online Role
Playing Games): genre with a set of shared
characteristics

5. NIME 2012, Munich, 30th July 2012
Introduction
 MMORPGs:
 Long-term avatars
 Missions, objects
 Soft real-time
 Fights, powers
 Levels

6. NIME 2012, Munich, 30th July 2012
Introduction
http://designcult.org/designcult/2010/08/mmo-subscription-charts.html

7. NIME 2012, Munich, 30th July 2012
Introduction
The most popular one: World of Warcraft (video)

8. NIME 2012, Munich, 30th July 2012
Introduction
 Other games (i.e. First Person Shooters) use
UDP, because they priorize interactivity
 But MMORPGs priorize secure transmission of
information: you can miss a shot in a FPS, but
you cannot miss a player buying a new sword
in an MMORPG
 Real-time requirements are looser
(although they exist)
 They use TCP instead of UDP

9. NIME 2012, Munich, 30th July 2012
Introduction
 But they are interactive:
 The speed of the player matters
 We have a real-time service using TCP

10. NIME 2012, Munich, 30th July 2012
Introduction
 Consequences of this fact (using TCP)
 Retransmission when a packet is lost
 Dependence on TCP variants, and on the
TCP stack present on player’s machine
 The game relies on the OS’s ability to deliver
packets
 More overhead (40 bytes instead of 28)

11. NIME 2012, Munich, 30th July 2012
Introduction
 TCP traffic of the game has to share:
 Access network
 Core network
with other TCP traffics (e-mail, FTP, etc)
 In this paper we will explore the effect of
TCP variants on this coexistence

12. NIME 2012, Munich, 30th July 2012
Index
1.
2.
3.
4.
5.
Introduction
Related Works
Test Methodology
Results
Conclusions

13. NIME 2012, Munich, 30th July 2012
Related Works
 Modelling traffic of MMORPGs
 Some statistical models have been
developed for MMORPGs
 Characterization of
 Packet size and Inter Packet Time
 APDU and Inter Arrival Time:
APDU of 1600 bytes
TCP stack of the computer
Packet 1: 1460 bytes of payload
Packet 2: 140 bytes of payload

14. NIME 2012, Munich, 30th July 2012
Related Works
 We will follow the second approach:
 Independent of underlying technology
 More adequate for modeling the behaviour of different
TCPs (if we have a concrete trace using a TCP variant, it
is not valid for the rest of variants)
APDU of 1600 bytes
TCP stack of the computer
Packet 1: 1460 bytes of payload
Packet 2: 140 bytes of payload

15. NIME 2012, Munich, 30th July 2012
Related Works
Characteristics of MMORPG traffic
 TCP
 Small packets, especially client-to-server
 A lot of ACKs
Traffic varies with player’s activities: Trading,
Questing, Dungeons, Player vs Player, etc.

16. NIME 2012, Munich, 30th July 2012
Related Works
TCP variants
 Some variants have been deployed in
order to solve certain problems (e.g. TCP
hybla for solving RTT unfairness, etc.)
 We will use three common TCP variants:
 TCP New Reno
 TCP SACK
 TCP Vegas

17. NIME 2012, Munich, 30th July 2012
Related Works
 Other studies have issued the problem of
real-time vs best effort traffic, but mainly
testing UDP vs TCP
 In this work, we are comparing
 TCP used for MMORPG
 TCP used for FTP

18. NIME 2012, Munich, 30th July 2012
Index
1.
2.
3.
4.
5.
Introduction
Related Works
Test Methodology
Results
Conclusions

19. NIME 2012, Munich, 30th July 2012
Test Methodology
 Network scenario: WoW session vs FTP
upload: the main problem is the uplink
WoW client
WoW server
WoW
512kbps
6Mbps
FTP
Tdejitter

20. NIME 2012, Munich, 30th July 2012
Test Methodology
 Bandwidth: corresponding to a xDSL
 Router buffer: 20 and 200 packets
 OWD: 80 ms (inter-region scenario)
WoW client
WoW server
WoW
512kbps
6Mbps
FTP
Tdejitter

21. NIME 2012, Munich, 30th July 2012
Test Methodology
 Traffic of the MMORPG
 Two flows: client-server and server-client
 We will use Questing activity, since it is the
most common one
 10 to 15 kbps
 Small packets (the game sets to 1 the “push”
bit in order to send them as soon as
possible)

22. NIME 2012, Munich, 30th July 2012
Test Methodology
 NS2 script that generates the scenario and the
traffic
 WoW: 2 flows of TCP SACK (commonly found
in player’s machines)
 FTP: NS2 implementations of TCP New Reno,
SACK and Vegas
 1000 seconds of simulation time

23. NIME 2012, Munich, 30th July 2012
Test Methodology
 Client-to-server packets
Inter Packet Time CDF - client to server
Packet Size CDF - client to server
1
1
0.8
0.8
0.6
0.6
0.4
0.4
0.2
0.2
0
0
0
200
400
600
ms
800
1000
1200
0
200
400
600
800
bytes
1000
1200
1400

24. NIME 2012, Munich, 30th July 2012
Test Methodology
 Client-to-server packets
Inter Packet Time CDF - client to server
Packet Size CDF - client to server
1
1
0.8
0.8
0.6
0.6
0.4
0.4
0.2
0.2
0
0
0
200
400
600
ms
800
1000
1200
0
200
400
600
800
bytes
1000
1200
1400

25. NIME 2012, Munich, 30th July 2012
Test Methodology
 Server-to-client packets
Inter Packet Time CDF - server to client
Packet Size CDF - server to client
1
1
0.8
0.8
0.6
0.6
0.4
0.4
0.2
0.2
0
0
0
200
400
600
ms
800
1000
1200
0
200
400
600
800
bytes
1000
1200
1400

26. NIME 2012, Munich, 30th July 2012
Index
1.
2.
3.
4.
5.
Introduction
Related Works
Test Methodology
Results
Conclusions

27. NIME 2012, Munich, 30th July 2012
Results
 Game
Buffer 200 packets
TCP window size
25
TCP window size
25
20
15
15
15
10
5
packets
20
packets
20
packets
TCP window size
25
10
5
0
5
0
0
100
200
300
400
500
600
700
800
900
0
0
1000
10
100
200
300
400
seconds
500
600
700
800
900
0
1000
100
200
300
400
seconds
500
600
700
800
900
1000
700
800
900
1000
seconds
 FTP
TCP window size
250
TCP window size
250
200
10
200
150
TCP window size
12
150
100
packets
packets
packets
8
100
6
4
50
50
0
2
0
0
100
200
300
400
500
600
seconds
SACK
700
800
900
1000
0
0
100
200
300
400
500
600
700
800
900
seconds
New Reno
1000
0
100
200
300
400
500
600
seconds
Vegas

28. NIME 2012, Munich, 30th July 2012
Results
 Game
Buffer 20 packets
TCP window size
25
TCP window size
25
20
15
15
15
10
5
packets
20
packets
20
packets
TCP window size
25
10
5
5
0
0
0
0
100
200
300
400
500
600
700
800
900
1000
10
0
100
200
300
400
seconds
500
600
700
800
900
0
1000
100
200
300
400
500
600
700
800
900
1000
700
800
900
1000
seconds
seconds
 FTP
TCP window size
80
TCP window size
12
80
70
10
70
60
60
40
30
8
packets
50
packets
packets
TCP window size
90
50
40
30
20
6
4
20
2
10
10
0
0
0
100
200
300
400
500
600
seconds
SACK
700
800
900
1000
0
0
100
200
300
400
500
600
700
800
900
seconds
New Reno
1000
0
100
200
300
400
500
600
seconds
Vegas

29. NIME 2012, Munich, 30th July 2012
Results
 The sending window of WoW behaves
differently from that of FTP
 The game is not trying to consume as much
available bandwidth as possible (as FTP does)
 It only has to send a continuous data flow of
small packets, at a rate of less than 10 kbps.
 Now we will discuss each buffer size

30. NIME 2012, Munich, 30th July 2012
Results
 Game
Buffer 200 packets
TCP window size
25
TCP window size
25
20
15
15
15
10
5
packets
20
packets
20
packets
TCP window size
25
10
5
0
5
0
0
100
200
300
400
500
600
700
800
900
0
0
1000
10
100
200
300
400
seconds
500
600
700
800
900
0
1000
100
200
300
400
seconds
500
600
700
800
900
1000
700
800
900
1000
seconds
 FTP
TCP window size
250
TCP window size
250
200
10
200
150
TCP window size
12
150
100
packets
packets
packets
8
100
6
4
50
50
0
2
0
0
100
200
300
400
500
600
seconds
SACK
700
800
900
1000
0
0
100
200
300
400
500
600
700
800
900
seconds
New Reno
1000
0
100
200
300
400
500
600
seconds
Vegas

31. NIME 2012, Munich, 30th July 2012
Results
 Added queuing delays
Average Queuing Delay
350
300 ms of queuing delay
300
buffer 200 packets
buffer 20 packets
250
ms
200
150
100
50
0
SACK
New Reno
Vegas

32. NIME 2012, Munich, 30th July 2012
Results
 Game
Buffer 200 packets
TCP window size
25
TCP window size
25
20
15
15
15
10
5
packets
20
packets
20
packets
TCP window size
25
10
5
0
5
0
0
100
200
300
400
500
600
700
800
900
0
0
1000
10
100
200
300
400
seconds
500
600
700
800
900
0
1000
100
200
300
400
seconds
500
600
700
800
900
1000
700
800
900
1000
seconds
 FTP
TCP window size
250
TCP window size
250
200
10
200
150
TCP window size
12
150
100
packets
packets
packets
8
100
6
4
50
50
0
2
0
0
100
200
300
400
500
600
seconds
SACK
700
800
900
1000
0
0
100
200
300
400
500
600
700
800
900
seconds
New Reno
1000
0
100
200
300
400
500
600
seconds
Vegas

33. NIME 2012, Munich, 30th July 2012
Results
 Added queuing delays
Average Queuing Delay
350
buffer 200 packets
300
buffer 20 packets
250
ms
200
150
Small queuing delay
100
50
0
SACK
New Reno
Vegas

34. NIME 2012, Munich, 30th July 2012
Results
 Game
Buffer 20 packets
TCP window size
25
TCP window size
25
20
15
15
15
10
5
packets
20
packets
20
packets
TCP window size
25
10
5
5
0
0
0
0
100
200
300
400
500
600
700
800
900
1000
10
0
100
200
300
400
seconds
500
600
700
800
900
0
1000
100
200
300
400
500
600
700
800
900
1000
700
800
900
1000
seconds
seconds
 FTP
TCP window size
80
TCP window size
12
80
70
10
70
60
60
40
30
8
packets
50
packets
packets
TCP window size
90
50
40
30
20
6
4
20
2
10
10
0
0
0
100
200
300
400
500
600
seconds
SACK
700
800
900
1000
0
0
100
200
300
400
500
600
700
800
900
seconds
New Reno
1000
0
100
200
300
400
500
600
seconds
Vegas

35. NIME 2012, Munich, 30th July 2012
Results
 Game
Buffer 20 packets
TCP window size
25
TCP window size
25
20
15
15
15
10
5
packets
20
packets
20
packets
TCP window size
25
10
5
5
0
0
0
0
100
200
300
400
500
600
700
800
900
1000
10
0
100
200
300
400
seconds
500
600
700
800
900
0
1000
100
200
300
400
500
600
700
800
900
1000
700
800
900
1000
seconds
seconds
 FTP
TCP window size
80
TCP window size
12
80
70
10
70
60
60
40
30
8
packets
50
packets
packets
TCP window size
90
50
40
30
20
6
4
20
2
10
10
0
0
0
100
200
300
400
500
600
seconds
SACK
700
800
900
1000
0
0
100
200
300
400
500
600
700
800
900
seconds
New Reno
1000
0
100
200
300
400
500
600
seconds
Vegas

36. NIME 2012, Munich, 30th July 2012
Results
 Game
Buffer 20 packets
TCP window size
25
TCP window size
25
20
15
15
15
10
5
packets
20
packets
20
packets
TCP window size
25
10
5
5
0
And this is bad for the game
0
0
0
100
200
300
400
500
600
700
800
900
1000
10
0
100
200
300
400
seconds
500
600
700
800
900
0
1000
100
200
300
400
500
600
700
800
900
1000
700
800
900
1000
seconds
seconds
 FTP
TCP window size
80
TCP window size
12
80
70
10
70
60
60
40
30
8
packets
50
packets
packets
TCP window size
90
50
40
30
20
6
4
20
2
10
10
0
0
0
100
200
300
400
500
600
seconds
SACK
700
800
900
1000
0
0
100
200
300
400
500
600
700
800
900
seconds
New Reno
1000
0
100
200
300
400
500
600
seconds
Vegas

37. NIME 2012, Munich, 30th July 2012
Results
 Game
Buffer 20 packets
TCP window size
25
TCP window size
25
20
15
15
15
10
5
packets
20
packets
20
packets
TCP window size
25
10
5
5
0
0
0
0
100
200
300
400
500
600
700
800
900
1000
10
0
100
200
300
400
seconds
500
600
700
800
900
0
1000
100
200
300
400
500
600
700
800
900
1000
700
800
900
1000
seconds
seconds
 FTP
TCP window size
80
TCP window size
12
80
70
10
70
60
60
40
30
8
packets
50
packets
packets
TCP window size
90
50
40
30
20
6
4
20
2
10
10
0
0
0
100
200
300
400
500
600
seconds
SACK
700
800
900
1000
0
0
100
200
300
400
500
600
700
800
900
seconds
New Reno
1000
0
100
200
300
400
500
600
seconds
Vegas

38. NIME 2012, Munich, 30th July 2012
Index
1.
2.
3.
4.
5.
Introduction
Related Works
Test Methodology
Results
Conclusions

39. NIME 2012, Munich, 30th July 2012
Conclusions
 TCP Vegas is able to maintain a constant rate
while competing with the game traffic, since it
prevents packet loss by avoiding the increase
of the sending window size.
 TCP SACK and TCP New Reno tend to keep on
increasing the window size, thus adding
undesired delays to the game traffic.
 Smaller buffers have been demonstrated to be
better for TCP-based MMORPGs, since larger
buffers cause higher delays

40. NIME 2012, Munich, 30th July 2012
Thank you very much