6QM Demonstration at IPv6 Spring 2004 Event










1. The Event

The IPv6 Spring 2004 Event has been considered to be a good opportunity to arrange a demonstration of the work done in the scope of the 6QM project. The organizers of the Event gave out heading to present applications and services that run in Next Generation Networks. The 6QM project demonstrated the developed measurement platform and showed how QoS parameters can be acquired for a user application running in an IPv6 environment.

2. Background

It is commonly understood that certain applications require a set of service parameters to be met by the network connection in order to work sufficiently. Based on measurements of QoS parameters of the network connection the access of a user can be optimized in aspects of - for instance - delay and delay variation. As a case in point for a user application with certain demands we have chosen to demonstrate a distributed gaming session with a few users sitting at their computers playing a realtime ego-shooter. The QoS of the network connection of a user has certainly impact on other user's perception in the gaming session. For instance a high delay or delay variation of a single user can slow down the scenery updates, mainly the coordinates of moving objects, that typically have to be sent from the server towards all player clients.

3. Demonstration Setup

As catch word we picked 'Online Gaming' - as already mentioned, we wanted to demonstrate a gaming session with some gamers spread around the globus. Accidentally we have 6QM project partners in Germany, Spain, France and in Japan. The figure below, the placard that announced our booth at the Event, depicts the setup of the demonstration, which extends several sites as mentioned afore. The subsequent paragraph will explain the details of the setup.

Demonstration Setup
Demonstration Setup Click to enlarge.

3a. Application Setup

One part implied by the planned demonstration was the setup of gaming server and clients. There are IPv6 versions respectively patches available for QuakeII server and clients for different Operating Systems that we could use. As can be seen in the figure several game components have been installed on project partner's premises and at the Event.
  • Gaming Server hosted in Berlin
  • Player in Berlin
  • Player in Brussels on the Event premises
  • Player in Madrid
  • Player in Tokyo (actually Kawasaki)
Also sketched in the figure is the flow of the game traffic (blue lines) - all gamers are connected to the game server located in Berlin. Every client sends player and object movements to the server that merges all positions and sends this information back to each of the clients.

3b. Measurement Setup

Second part of demonstration setup was to establish the measurement infrastructure which includes connecting measurement probes near the participating players - indicated in the figure by the blue boxes decorated with magnifying glasses. The probes sent their measurement data to an OpenImp collector hosted in Madrid coexisting with the OpenIMP Measurement Controller. The controller was in charge to configure the distributed measurement probes upon measurement configuration.
  • Measurement Controller, Collector and Evaluator hosted in Madrid
  • Passive Probe at Player's client in Berlin
  • Passive Probe at Player's client in Brussels
  • Passive Probe at Player's client in Madrid
  • Passive Probe at Player's client in Tokyo
As the OpenIMP Measurement Controller supports Web-based remote access we could easily demonstrate measurement setup and results from the Event location to the interested attendance.

4. Exemplary Measurement Result

Below we present results of a conducted measurement. The network offered only best-effort service, but we wanted to know some more ...
All gamers were connected via native IPv6 connectivity. We conducted passive measurements which directly examine the traffic of the application. (In contrast to active methods that generate artificial test traffic.) The measurement included all traffic senders and receivers concurrently. As an example, the qualitative characteristics of the acquired one-way delay (plotted over measurement period) can be seen in the figure below:
  • Germany: relatively low one-way delay in forth and back direction since client and server are co-located.
  • Spain: higher delay in both directions (in reference to Germany). Interestingly, we observed the rather high variation of the delay from the server towards the client (compared to opposite direction).
  • Japan: Understandably, we see the highest one-way delay for both directions from and towards the game server presumably caused by the physical distance of client in Japan to the game server in Germany. Although one would expect a high delay variation for this connection we experienced it for the case Spain - Germany.
server-clients delay
Server-Client Delay Click to enlarge.

clients-server delay
Client-Server Delay Click to enlarge.

5. Conclusion

We presented the measurement application OpenIMP that has been developed in the scope of 6QM project. We demonstrated it by means of examining a user application running within Next Generation IPv6 network. The interested audience could gain insight into the intention and the applicability of QoS measurements.
members area you are accessing this server via IPv4
from 3.147.44.149
  webmaster@6qm.org