WP3 – Use-case trials

Objectives

  • Learn from deployment of the developed mechanisms.
  • Evaluate the efficiency of the developed mechanisms for the RITE use-cases of financial applications, online games and interactive video
  • Research best practice parameters to tune the developed mechanisms for a range of applications based on study of the chosen use-cases.
  • Evaluate the potential for exploitation of RITE mechanisms

Description of work

Fully understanding and evaluating the benefit of RITE mechanisms can only be done using deployed applications. While the developed mechanisms will be generally applicable, the RITE work plan is therefore based on three select use cases: online gaming, financial trading applications and interactive video conferencing. Work in WP3 is focused on use case trials in these application areas. The WP is structured into 6 tasks. Work in the WP starts in task 3.1 with gathering of data sets for requirements analysis and use in evaluation of RITE mechanisms. The data gathering in task 3.1 serves as an initial verification of the planned use case trials. The use case tesbeds and test environment will be finally prepared for use case trials in task 3.2. Deployment and evaluation of RITE mechanisms in use case trials are then carried out in tasks 3.3, 3.4 and 3.5. Task 3.3 addresses use case trials for online gaming in a game company live test environment. As a live test environment, it offers a unique opportunity to test RITE mechanisms with real users, while the tested RITE mechanisms are restricted to end system solutions. Task 3.4 addresses use case trials for financial applications in a BT low-latency testbed. While all RITE mechanisms can be evaluated in this testbed, it is particularly suitable for evaluation of jointly optimized network and end system mechanisms as it represents a use case with a controlled network environment. Task 3.5 addresses use case trials for interactive video in and Alcatel-Lucent testbed. All developed RITE mechanisms are applicable for evalu- ation in this testbed/use case. Based on results from the use case trials as well as input from WP1 and WP2, task 3.6 defines a set of guidelines for how to tune RITE mechanism parameters for best possible latency. Task 3.6 will start at the beginning of the project and initially consider how to tune currently deployed mechanism for latency.

Task 3.1: Traffic pattern analysis and data set acquisition

Description: This task will perform an analysis of the three applications: financial applications, online games and interactive video. Different time-dependent applications have different traffic patterns, yielding different network behaviour. This task will select representative candidate applica- tions for the three use cases. Data sets for the chosen use-cases will be gathered and analyzed to assess their requirements and to prepare for deployment of experimental prototypes in the partner testbeds and/or on the Internet. The gathering of these traces will be done by dedicated experimentation in controlled testbeds and/or by gathering information of actual deployments. The data obtained and analysed will also be used to evaluate developed RITE mechanisms in tasks 1.2, 1.3, 2.2 and 2.3 as they can provide data patterns for lab test replay and basis for simulation design.

Task 3.2: Preparation of testbeds for use-case trials

Description: Testbeds and live test environments for the chosen use cases of financial applications, massively multiplayer online games and interactive video will be prepared for the use-case trials. This task will assess the different properties of each use-case environment to support a complete, and fast, deployment of the mechanisms proposed in WP1 and WP2. The preparation will also ensure that proposed end-system mechanisms and network mechanisms are compatible with each other and the use-case environments. This task also includes the integration of test and measurement tools into each environment, to enable both the verification of proposed mechansisms and the evaluations described in tasks 3.3, 3.4 and 3.5.

Task 3.3: Deployment and evaluation of end system mechanisms for online gaming in a live test environment

Description: end-system mechanisms for low latency will be deployed and tested by implementing changes on a game server for an actual running online game. The game servers will be hosted in the cloud, and will be accessed by players from a wide range of different platforms including browsers on different operating systems, iOS and Android. The mechanisms may be evaluated on a test instance of a game server, where paying customers are allowed to experience new game features before the full launch on the regular production servers. If the evaluated mechanisms are deemed safe for full deployment, it will be tested on the main servers of a live game. By employing end-system techniques that all possible clients for the game service may benefit from, data can be gathered for evaluation of the mechanisms in real-life scenarions. The measured effect of the mechanisms can be evaluated together with the experienced effect. Mechanisms for evaluation may include multilink strategies, API enhancements, host buffer modifications and protocol optimisations. This task will build on the traffic data set acquisition and pattern analysis from task 3.1 and the developed mechanisms from tasks 1.2 and 1.3.

Task 3.4: Deployment and evaluation of RITE mechanisms for financial applications in a BT low-latency testbed

Description: The BT-Radianz test & trial process is primarily designed to certify the integration of new releases of equipment from suppliers. It is designed to be comprehensive and exhaustive in order to protect live finance services from any risk of disruption by new equipment or practices.

RITE outputs will only be considered for testing if they show strong benefits in the evaluations carried out in WP1 and/or WP2. The BT-Radianz network itself contains many bespoke modifications to BT’s generic network products that have been developed for particular customers. BT’s test processes for these bespoke additions are currently being modified to accommodate testing of innovative research proposals, with the idea that the new process will be usable for future innovation initiatives from BT’s Research & Technology division, such as those expected from RITE.

Targeted Tests: Bespoke enhancements to the service are tested in the London test facility, by connecting together sufficient equipment to emulate the live network. No single testbed exists, as multiple tests are being conducted at any time, each using separate equipment and separate connectivity. Equipment representative of the live network is drawn from a central pool, and configurations are used that reflect those in the live network. RITE mechanisms will be tested against financial application traffic patterns. This task will therefore build on the traffic pattern analysis of task 3.1 and the mechanisms developed in tasks 1.3 and 2.3. If the BT-Radianz product team likes the proposed changes, considerably more testing may be required. If the changes are solely to practices or configurations, they may go straight to testing on the live network testbed. If however, changes to vendor equipment are required, these will have to be added as requirements in future competitive tenders, then pass through the whole vendor testing process. This last process will necessarily be completely independent of RITE, and unlikely to complete during the project.

Task 3.5: Deployment and evaluation of RITE mechanisms for interactive video in an Alcatel-Lucent testbed

Description: This task involves the deployment and evaluation of selected mechanisms developed in WP1 and WP2 for the interactive video application. The target is to assess the improvements generated by the network and end-system mechanisms for this application. The task will build further on the analysis performed in task 3.1. For the RITE project, Alcatel-Lucent will construct a testbed covering the full distribution chain for interactive video applications. This will cover end-devices, residential gateways, access and aggregation routers, core routers and equipment for generating extra load. The devices fulfilling these roles will be a mix of actual equipment and Linux/FreeBSD emulation nodes, the latter can be used to experiment with the techniques that will be developed in the RITE project. The testbed will be connected to the Internet for signaling traffic for selected applications (e.g. Skype, FaceTime). For the end-devices, a set of representative client devices will be chosen.

Task 3.6: Definition of recommended use parameters

Description: This task will define a recommended set of parameters based on the experimental results using the deployed mechanisms. These parameters will provide guidelines to businesses and application designers that can benefit from the deployment of the next generation low-latency applications. In the beginning of the project, parameters for configuring existing mechanisms for the best possible latency will be assembled. In some cases, we believe that considerable improvement in latency can be obtained only by tuning parameters correctly. As the project progresses, parameters for tuning RITE mechanism parameters for the best possible result will be the focus of this task. In providing configuration recommendations special care will be taken as to explain how different mechanisms interact and the need for any joint parameter tuning.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s