AREAS AND ORGANISATIONAL STRUCTURE - PHASE 2

The project team will consist of the QoS Architecture Group and a number of Working Groups (WG) as shown below. The QoS Architecture Group steers the project and coordinates the activity of the WGs.

• Architecture Group meetings: minutes and presentations [private area]

Each WG corresponds to a specific project activity area and has its own objectives (to see the objectives please click on the corresponding rectangle).

Applications Requirements

1. To further understand the impact of QoS deployment on a range of applications and the associated impact on all user experience.
2. To co-ordinate and participate in experiments with partner sites which have been suitably configured with QoS on their campus and regional networks, and to broaden the trials to include more sites with a wider variety of connection bandwidths and network implementations as dictated by the hardware in use at new participating member sites.
3. To extend the range of test applications beyond those used in Phase 1 and under a wider range of conditions.
4. To consider end-user applications which are candidates for Premium class: videoconference, access grid, VoIP, streamed media.
5. To consider end-user applications which are candidates for LBE class: student halls commodity traffic, large overnight media content updates for NWGfL.
6. To study the impact of congestion on network applications such as DNS updates and requests, dynamic routing protocols.
7. To report to the JANET community and provide summaries of results, benefits and drawbacks experienced.

Policy & Management

The main goal of the PM WG is to develop policy rules and operational procedures for a static QoS service model. A secondary goal will be to investigate the feasibility of using the same rules and operational procedures for a dynamic bookable QoS model that could be deployed as an advanced feature for some domains.

The objectives of the PM WG are as follows:

• To review the QoS service features requirements of the JANET community by distributing a QoS questionnaire and analysis of the responses received from the community.
• To define the description of the individual QoS classes. This should be based on the three QoS services (IP Premium, Best Effort and Less than Best Effort) explored during Phase 1. All other existing proposals/implementation of possible QoS classes should be explored (at least theoretically) and evaluated against JANET applications requirements.
• To define the policy and provisioning/operational parameters and procedures for a static QoS model and create plans for development (based on the Phase 1 documents: Policy framework document developed by Chris Cooper, Description of QoS classes developed by Victor Olifer and the policy document developed by GEANT2 SA3)
  • Define the key policy parameters and the recommended range for each of the JANET domains: SJ4/5; Regional Networks/RBCs; Campus Networks (to take into account the different types of campus networks, e.g. Universities, FE and Schools);
  • Define admissions control procedures and parameters for each of the JANET domains, taking into consideration that a static QoS model can use some dynamic elements – the most obvious could include dynamic authentication and admission control procedures.
• To explore and define policy and provisioning/operational procedures (advance and on-demand booking) for a dynamic QoS model as a secondary model.
• To develop policy and provisioning/operational procedures for a hybrid static/dynamic QoS model, which combines static provisioning for some application types (e.g. short-term VoIP sessions) and dynamic provisioning procedures for others (e.g. videoconferencing sessions), according to the applications and their users’ requirements.
• To develop QoS SLD/SLAs templates for each type of JANET domain.
  • It is anticipated that these templates should be different for top-level and low-level domains, according to specific user requirements and a number of individual flows (for example, top-level domains SLD/SLA need to be scalable enough to apply to thousands of individual flows as classes, and low-level domains should take into account every individual user)
  • SLD/SLA should be differentiated not only by the type of domains but also by stages of QoS services deployment. This means that during the initial stage of the deployment, both the providers and users will have very limited experience in the QoS area, therefore these SLD/SLA should be quite loosely defined, e.g. QoS classes should be measured quantitatively rather than qualitatively. It should also give providers and users of the QoS services some freedom in gradually increasing QoS strength without introducing conflicts to the strict SLD/SLA that have been defined. For some low-level domains it is possible only to have an SLD between the provider and its users during the early stages of the deployment; however, the project work group should take into account the complexity involved in measuring the SLA parameters for each individual user.
• To participate in developing guidance documentation for the JANET community such as user guides, cookbooks, best practice documents etc.; also, to act as reviewers for documents that are produced by other work groups.

Technological Interworking

1. Survey the user community for current network performance issues, with a view to understanding which issues are a priority from a practical perspective. The results of this survey should be considered in prioritising the work of the Tech WG. Trends in queries to the BMAS service may also help shape priorities.
2. Scope and prioritise the technical issues, focusing on the current practical issues ahead of medium to long term technologies. Liaise with the Apps WG to understand how the applications and various technologies interact (e.g. firewalls, proxies).
3. Define the Tech WG methodology for experiments, and the requirements for the measurement and monitoring tools. It is likely the Tech WG will need to measure performance between adjacent hops on test traffic paths.
4. Identify and summarise WG (inter)dependencies.
5. Identify technologies that have end-to-end test requirements for the trial phase. An initial assessment suggests that that may only be multicast.
6. Carry out tests and trials of technologies. Draw applications from the Apps WG and specific configurations for tests from the Deployment WG.
7. Report on the solutions for issues, and any open/unresolved issues.
   

Monitoring & Measurement

The objectives of the Measurement Workgroup in the JANET QoS Trial reflect the wider ongoing development on Network Performance  Measurement by JANET(UK) across JANET.

The JANET Network Measurement Project’ objectives are to:

• Deploy performance measurement points at strategic points on the JANET network.
• Deploy a flexible data collection and storage infrastructure to gather JANET performance measurement data from the measurement points in point one above as well as from existing measurement devices such as JANET Netsight and router SNMP data.
• Evaluate the available methods of analysing and visualising network performance measurement data.
• Assess user requirements and gather feedback from participating JANET connected organisations on the usefulness, and suitability, of performance data provided through a range of trial interfaces.
• Provide recommendations to the SJ5 project in relation to performance measurement architectures.

Additional objectives that should meet the needs of the Quality of Service Trial are:

• Utilize the JANET Network Performance Measurement Trial infrastructure to gather performance statistics through the classes of service deployed across JANET as part of the JANET QoS Trial Phase 2
• Develop a user interface that allows participants to view the gathered data in a flexible manner that reflects the needs of the trial.
• Explore the possible design of a SLA monitoring system for future JANET deployment
• Explore the possibility of automating (e-mail, SMS) performance alerts based on the classes of service and gathered performance metrics.
• Explore the possibility of developing baseline metrics for each class of service that could be used in the future development of the QoS measurement system.
• Explore and evaluate the capabilities of automatic bandwidth estimation tools such as Cisco’s IOS embedded Corvil Bandwidth software.

Implementation & Deployment

Overall goals for the Implementation and Deployment Working Group are:

1. Tackling issues that arise when considering deployment of QoS to end sites connected to JANET, and
2. Bringing together the results of the edge tests, the Application Requirements Working Group and the Technological Interworking Working Group, and applying them to the end-to-end JANET model.

The ID WG objectives are:

• Extend the range of QoS solutions towards peripheral parts of JANET
• In conjunction with Technological Interworking Group
• Schools and FE institutions
• Specific features of links, low speed, low cost, zero maintenance
• Static provisioning
• Monitoring of links and provision for associated feedback
• Participate in and monitor tests
• Observing and helping to solve implementation problems that might appear
• Pull together results from individual trials in order to create a coherent big picture of the end-to-end scenario
• Convert results from this and other Working Groups into best practice guidelines in the form of an evolving cookbook, containing:
• Trial results (i.e. "What did we learn")
• Administrator and user guidance for the community
• Consideration for specific parts of JANET, or specific scenarios
• Consideration of the impact of changes in equipment and infrastructure
• Hardware config examples and issues gathered from other trialists
• Production of an overall blueprint for QoS implementation and deployment across JANET