A Relative Delay Minimization Scheme for Multiplayer Gaming in Differentiated Services Networks Brian Carrig
David Denieffe
John Murphy
Institute of Technology, Carlow Kilkenny Road, Carlow Ireland 00 353 59 9171400
Institute of Technology, Carlow Kilkenny Road, Carlow Ireland 00 353 59 9171400
University College Dublin Belfield, Dublin 4 Ireland 00 353 1 7162928
[email protected]
[email protected]
[email protected]
available at different prices, users should be able to signal and demand from the network the selected services. Regardless of whether such prices are set dynamically or statically, it is clear that multiplayer gaming in such an environment will be different to that enjoyed by games players today.
ABSTRACT Multiplayer gaming over the Internet continues to grow in popularity, despite a lack of Quality of Service (QoS) mechanisms. Future QoS-aware networks such as those based on the Differentiated Services (DiffServ) framework will provide an opportunity for gamers to enhance their game-playing experience. An important QoS metric for networked games is a user’s delay relative to the delay of other users. In this paper, we propose a Relative Delay Minimization (RDM) algorithm for use in DiffServ environments. Simulation results are described and presented showing that the algorithm can reduce the Relative Delay Variation (RDV) between users in a DiffServ environment.
First Person Shooter (FPS) games, like Counterstrike, are particularly sensitive to latency. Counterstrike itself has over 19.5 million legal owners and an average of over 85,000 simultaneous players at any one point in time, according to the popular gaming website, GameSpy. This popularity has ensued even within the best-effort framework of current networks. Although it could be argued that gamers are perhaps insensitive to QoS, surveys such as that described in [2] indicate that this is probably not the case. It is safe to assume that delay will continue to be of concern to gamers in the future. Jitter is also a concern but many researchers assert that transit delay is the biggest issue for games [3]. Within DiffServ networks, however, gamers will be able to indicate their delay sensitivity. At the same time, simply marking all of their traffic as high priority may involve unnecessary expense for the gamer.
Categories and Subject Descriptors C.2.4 [Computer Communication Networks]: Distributed Systems – Client/server
General Terms Algorithms, Performance.
Any network which supports multiple service classes requires a differentiated pricing structure to allocate traffic to classes rather than relying on the flat-fee model currently adopted by most Internet Service Providers (ISPs). Where multiple services are
Of equal, if not greater importance, in a group communication environment are variations in QoS between members of a group. This relative QoS may be defined as the difference in absolute QoS among users in a group communication environment. Gamers have previously indicated that they consider relative delay to be important to their overall game playing experience [4]. Many papers, such as [5], perceive relative delay to be a fairness issue. They advocate introducing additional delays to some users in order to provide a "level playing field" for players. In [6] an algorithm for reducing Relative Delay Variation (RDV) in multiparty group communications is advocated. This algorithm is suited to applications with a client-server architecture operating within a DiffServ environment. The server actively monitors the delay of all connected clients and where the RDV is above a certain threshold, a message is passed to the client with the largest delay to increase the priority of their traffic.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Netgames'06, October 30–31, 2006, Singapore. Copyright 2006 ACM 1-59593-589-4. $5.00.
In this paper we introduce a Relative Delay Minimization (RDM) algorithm for reducing relative delay among gamers in a DiffServ networking environment. This algorithm is applicable to the client-server model for networked gaming applications and could be readily expanded for other forms of relative QoS, such as relative packet loss or relative delay-jitter. Central to the functioning of this algorithm is the idea that users will be able to actively indicate their traffic class preferences to the network.
Keywords Network Games, Relative Delay, DiffServ, QoS
1. INTRODUCTION The Differentiated Services (DiffServ) framework [1] provides Quality of Service (QoS) classes for IP networks. Currently two service models are defined by the IETF for DiffServ forwarding. Premium service, using the Expedited Forwarding (EF) Per-HopBehavior (PHB) and the Assured Forwarding (AF) PHB based on statistical provisioning.
1
The rest of this paper is organized as follows: In the next section we provide describe the proposed RDM algorithm. Section 3 describes the simulation designed to test this algorithm and the results of multiple simulations are shown in section 4. We conclude the paper with a discussion of its main contributions.
2. RELATIVE DELAY MINIMIZATION 2.1 Algorithm The algorithm is designed for use with unicast streams, as online games rarely perform multicast streaming. As indicated in section 1, the Relative Delay Minimization (RDM) algorithm assumes that a client-server architecture is in place. Unlike the algorithm proposed in [6], it is a client controlled algorithm and does not place any extra traffic on the network. The mean delay of the connected clients is calculated by individual clients using information distributed by the server. A game-dependent threshold is configured for each client, where the client has a roundtrip delay greater than the threshold and the mean they will increase the priority of their traffic. If their delay is lower than the value of the mean minus the threshold, they will decrease the priority of their traffic. It is an adaptive algorithm, as users must adapt their traffic dependent on the delays of other users connected to the server.
Di = αDi −1 + (1 − α ) M i
(1)
The purpose of the algorithm is to reduce the variation, or spread, of absolute delay ranges into a tighter bound centered on the mean absolute delay value. The mean absolute delay value should not noticeably increase or decrease and overall costs should remain relatively static. The greater the number of AF classes, the more accurate the algorithm will be in achieving its objectives. With more classes a finer level of granularity can be achieved.
2.3 Relative delay variation To monitor the success of the algorithm, a standard deviation measure can be applied. Standard deviation is the most common measure of statistical dispersion or spread of values and can be referred to as Relative Delay Variation (RDV) in this context. It can be denoted as δ and is calculated using eq. (2). Where di is the delay experienced by the ith client and µ is the mean of these delays. N is the total number of clients connected to the server. The closer to the mean the delay values are, the closer to zero the RDV figure is. It provides an easily interpreted benchmark for the success of the algorithm and will be used in this paper for comparative purposes. N
The pseudo-code of the modification algorithm is given below and is triggered whenever a client receives a packet from the server. packet p received if delay > mean + threshold if priority can be increased increase priority else if delay < mean - threshold if priority can be decreased decrease priority
δ=
∑ ( x(i) − µ )
2
i =1
N
(2)
3. SIMULATION SETUP The following experiments were carried out using the NS-2 simulator [7] with a Counterstrike traffic generator module. This traffic generator has been modified by the author on the client side to include the RDM algorithm. The server has also been modified to distribute information to the client regarding the mean absolute delay of connected clients.
The threshold value defines the upper and lower bounds of relative delay in which we wish the game to be played. Games with high interactivity requirements will require a low threshold value. The value delay denotes the current roundtrip delay time and mean is the current mean of the absolute roundtrip delay times of connected clients. If a client has an absolute delay time lower than the mean minus the threshold value but cannot decrease the priority of his traffic then no action is taken. Likewise, if a client has an absolute delay time greater than the mean plus the threshold but cannot increase his sending priority then no action is taken.
2.2 Delay calculation Delay is measured using an Exponentially Weighted Moving Average (EWMA) of the roundtrip time as shown in eq. (1). The use of a EWMA is not strictly necessary and many games simply use an average. However, the use of a EWMA adds historical data helping to smooth any temporary or transitory delay while giving precedence to the most recent delay values. Di is the average after the ith sample; Mi is the ith measurement and α is 0.94. This is a commonly used decay value, providing sufficient smoothing in a volatile series of data points.
2
Figure 1. Network topology
3.1 Topology We simulate a single DiffServ domain considering gaming performance both with and without relative delay minimization. A pool of 240 clients is connected to this domain, the topology of which is shown in Figure 1. The topology contains 3 core nodes, 80 access nodes, 280 end nodes and 1 game server. The propagation delays of the links between end nodes and access
The 5th Workshop on Network & System Support for Games 2006 — NETGAMES 2006
nodes are varied slightly to prevent any global synchronization issues. The links connecting the backbone links are 10Mb/s and the links connecting the access nodes to the backbone nodes are 5Mb/s. The links connecting the access nodes to the end nodes are 3Mb/s and the link connecting the game server to one of the core nodes is 5Mb/s.
3.2 Model Clients join the game server according to a Poisson process, where λ = 1 new client per 30 seconds and the game duration is an exponentially distributed 300 seconds. A strict priority scheduler is implemented at each node; giving preferential treatment to AF10, AF20 and AF30 respectively. Thus packets in the AF40 queue are only forwarded when the preceding queues are empty. To reduce complexity, only a single drop precedence is used. Due to the low bandwidth nature of multiplayer FPS games, such users are unlikely to exceed their service profile constraints and have their traffic marked with higher drop precedence. For similar reasons, no Active Queue Management (AQM) scheme is employed. Background traffic sources generate traffic according to an exponential on-off pattern and the traffic volume is spread proportionally across the AF classes in a 1:2:3:4 ratio for AF10, AF20, AF30 and AF40 respectively. Thus AF10 receives approximately one tenth the volume of traffic of AF40. The overall background load is varied between light, medium and heavy for each of the different access links and changes continuously over time throughout the course of the simulation. The value of the threshold component of the RDM algorithm is set at 25ms. This provides a range of 50ms and although there have been few quantitative evaluations of relative delay requirements, with absolute delays of sub-50ms most gamers exhibit satisfaction even when playing highly interactive games [8]. We regard this as a good relative delay bound for interactive gaming. The metrics used to evaluate the simulation are RDV, mean absolute delay and cost. As mentioned in the introductory section, in order to differentiate between traffic classes on a network, differential pricing must also exist. For the purposes of this experiment we assume that a packet incurs a monetary unit cost of 0.1, 0.2, 0.3 and 0.4 for traffic classes AF40, AF30, AF20 and AF10 respectively. Although exact pricing on a communications network will remain a function of marketing and other policy related factors, we are simply seeking to establish that introduction of the algorithm does not greatly increase or decrease the overall costs involved. It would be of great interest to evaluate the perceived user-benefit based on an applicable utility function and monitor any changes invoked through use of the RDM algorithm. However, no such utility function could be obtained and it remains an area for further human factor research.
4. SIMULATION RESULTS 4.1 Costs Table 1 gives the total costs incurred for when the RDM algorithm is employed and when it is not. This is further subdivided based on the number of forwarding classes available. Where only one forwarding class is available, both RDM and noRDM simulations yield the same results (since the user cannot upgrade or downgrade his or her traffic). Interestingly, once the
number of available forwarding classes is increased, although costs the increase slightly for the RDM simulation, they do not increase by a significant amount. This is especially true where 4 AF classes are available, with just over 2% difference between the two. When more classes are available, the algorithm is more finegrained. To further highlight this, the greatest discrepancy between the two results occurs when there are only 2 AF classes available. In this case, there is almost a 6% difference between the two sets of results.
Table 1. Total costs incurred during simulation AF Classes
Monetary units RDM
Non-RDM
1
64,621
64,621
2
75,058
70,679
3
72,477
71,050
4
71,845
70,197
4.2 Priority changes The information provided in Table 2, reinforces this viewpoint. Here the number of upgrades and downgrades for the RDM algorithm are shown. Although the numbers are not in an exact 1:1 ratio, nevertheless they are roughly proportional. The purpose of the algorithm is not to reduce absolute delay across all users but to ensure that all delays are kept within a tighter range. For some users, this may mean increased delay, for others lower delay. However, since we are only reducing the variation between delays rather the delay itself, mean absolute delay should not vary significantly. Table 2. Priority changes for RDM algorithm AF Classes
Number of changes Upgrades
Downgrades
1
0
0
2
175,980
162,738
3
166,640
179,307
4
166,873
160,175
4.3 Mean absolute delay Figure 2 shows the mean absolute delay experienced by clients, averaged over the course of one simulation, where 4 AF classes are available. The data is presented from both RDM and nonRDM simulations. What is evident is that the mean values are quite similar for both sets of experiments. On the bottom axis, the number of available priority classes is given. Thus we can observe that as the number of available priority classes increases, the mean delay values become less divergent. As indicated previously, this is due to the finer QoS granularity offered by having a larger number of AF classes available.
The 5th Workshop on Network & System Support for Games 2006 — NETGAMES 2006
3
Delay in Milliseconds kkk
Average Mean Roundtrip Delay 108 106 104 102 100 98 96 94 92 90 88
No-RDM RDM
0
1
2
3
4
5
Number of Available Classes
Figure 2. Average mean roundtrip delay values
4.4 Relative delay variation The simulation data above indicates that there is little disincentive to implement the RDM for networked game playing in a DiffServ environment. However, of much greater importance is that there is sufficient incentive to implement such an algorithm. As outlined in section 2, RDV or the standard deviation of absolute delay, will be used as a comparative metric. Figure 3 shows the average RDV value for an entire simulation. Results are compared for both RDM and no-RDM experiments, with different numbers of forwarding classes available. As the number of classes increases, the RDV decreases. Thus when there are 4 available AF classes, using the RDM algorithm offers a 55% improvement over the noRDM case.
In this article we have presented a relative delay minimization algorithm to be implemented on client machines, within a clientserver game playing architecture, for DiffServ networks. The proposed algorithm seeks to keep the absolute delay of the client within certain bounds of the mean absolute delays of all connected clients. It does so by increasing or decreasing the priority of traffic as appropriate. Simulation results are provided to demonstrate that the proposed algorithm can indeed offer performance improvements. Mean absolute delay and associated costs were neither increased nor decreased significantly. However, where all 4 assured forwarding classes were available, the relative delay variation between clients is reduced by a considerable 55% when the RDM algorithm is used. Greater benefit is offered by the algorithm in heavily-loaded networks as a greater proportion of the delay experienced by clients is caused by queuing delay rather than processing or propagation delay. The algorithm is redundant in networks where only one level of service provided and its benefits are mitigated in situations where the delay is not due to queuing time. The reliance on user altruism is also of concern. Game playing is a competitive environment and users may be unwilling to increase their absolute delay for the benefit of others. Similarly, users may not wish to incur the additional costs of increasing the priority of their traffic, in order to reduce their absolute delay. It is possible that admission control or upper and lower thresholds on absolute delay could be introduced for such situations.
Average Relative Delay Variation Values
6. REFERENCES
160
[1] S. Blake et al., “An architecture for differentiated services”, IETF RFC 2475, Dec. 1998.
140
RDV in milliseconds
120 100 No-RDM
80
RDM
60 40
[3] S. Cheshire, “Latency and the quest for interactivity”, Nov. 1996. http://www.stuartcheshire.org/papers/LatencyQuest.ps
20 0 0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
Number of Available Classes
Figure 3. Average relative delay variation values Similar trends are evidenced when simulations with lighter or less varied loads are run. However, the level of improvement offered by the RDM algorithm in these circumstances is significantly lessened. This is because in lightly loaded networks, much of the delay variation is due to differences in propagation delay between the clients, rather than queuing delay.
5. CONCLUSIONS The growth in popularity of networked games and consequent growth in Internet traffic volume is likely to continue for the foreseeable future. DiffServ networks, offer possibilities for improving the game-playing experience for gamers. Latency is considered to be one of the most important QoS metrics for interactive games and as such has received a great deal of attention. Less studied but also of considerable importance is the issue of relative delay.
4
[2] T. Henderson and S. Bhatti, “Networked games: A QoSsensitive application for QoS-insensitive users?” In Proceedings of ACM SIGCOMM 2003 Workshops, p. 141147, Aug. 2003.
[4] T. Henderson, “The effects of relative delay on networked games”, Ph.D. thesis, University of London, London, UK, April 2003. Available online at http://www.cs.dartmouth.edu/~tristan/pubs/thesis.pdf [5] S. Zander, I. Leeder and G. Armitage, “Achieving fairness in multiplayer network games through automated latency balancing”, In Proceedings of ACM SIGCHI ACE2005, Valencia, Spain, 2005, pp.117-124. [6] L. Liang, Z. Sun and H. Cruickshank, “Relative QoS optimization for multiparty online gaming in DiffServ networks”, In IEEE Communications Magazine, vol. 43, no. 5, May 2005, pp. 75-83. [7] NS v2 Simulator. http://www.isi.edu/nsnam/ns [8] L. Pantel and L.C. Wolf, “On the impact of delay on realtime multiplayer games”, In Proceedings of ACM Network and Operating Systems Support for Digital Audio and Video (NOSSDAV’02), Miami, Florida, May 2002, pp. 23-29.
The 5th Workshop on Network & System Support for Games 2006 — NETGAMES 2006
