The objective of this session is to introduce the Vendor
Challenge to the industry and the European Real-Time community and to
solicit feedback from the participants on how to make the challenge as
effective and engaging as it can be.
This session will outline the requirements and the
scenarios that have been put forward thus far by the "QoS Real-Time
Requirements" Project . This session will solicit feedback
and discussion to refine the requirements for the challenge and refine
the options for scenarios. The goal is to issue the challenge in
Q2 of 2003.
The challenge will focus around guidelines for
integrated QoS that account for Real-Time Requirements with particular
attention to:
- Dependable Timeliness - indicative of real-time application
requirements
- QoS/Real-Time application patterns in various programming enclaves
(e.g. procedural, database, parallel, and potentially safety
critical)
- Real-Time metrics for Integrated QoS
- Aggregate Systems
The expected outcome of this session is:
-
Increased awareness of the challenge.
-
Increased participation - initially in the planning,
and ultimately in stepping up to the challenge, particularly from
the European arena.
-
Refined requirements for the challenge and a firmer
description of the scenario to be used in the challenge itself.
Sally Long explained the role of Real-Time in the work of the Quality
of Service Task Force. Her slides, in pdf format, are here
Doc Allen presented her view of the requirements for a scenario for a
challenge. Her slides (pdf) are here
- It should prepresent an aggregated system included at least two
enclaves (such as database (parallel) and Procedural (safety
critical).
- Dependable end-to-end timeliness should be required for some of
the applications.
- The scenario should be performance challenging, but achievable.
- It should involve enterprise integration - there should be a QoS
framework
- Individual applications should be 'do-able'
- The scenario should involve non-real-time applications
- A multi-lingual environment is not required, but should not be
excluded
- There should be some dynamic workloads
- There should be a separation between analytical versus
demonstration versus other types of evidence
- Define level and type of dependability and the measurement
approach
- Need to show different loads on different resources to show that
the solution is robust.
- Solutions need to be robust to the independent evolution of
application requirements
- Remember policy driven Q0S (multi-dimensional)
Dock then presented a potential scenario based on
Jean Hammond then presented a Navy SLA scenario which had been
received from Deborah Goldsmith of Mitre Corporation. The system
is designed to be on-ship, designed to carry regular applications such
as VoIP together with time critical systems. There is a series of
differnet interconnects between the ships and the rest of the
system. There are some emerging requirements in terms of delay
priorities; the scenario brings together traditional command-and-control
systems and the traffic requirements of a small city.
Dock then led a discussion of possibilities for other potential
scenarios:
- Telco - felt to be too complicated.
- Something like a CNN news-gathering service - because of the need
to almost instantaneously reset prioritities, and the need to take
feeds from different locations and to use them differently.
Charles Richmond has good contacts in Akamai.
- Neil Davies had spoken to an organisation which was a potential
source of a scenario, but they had not agreed.
- Dave Lounsbury outlined a publicly available scenario for future
combat systems, utilising Command and Control systems and weapons,
where the terrain frequently masked the signal and the system had to
cope with jamming, and everything changed from moment to
moment.
- Neil Davies suggested ad hoc 802 networking as a scenario
- Joe Bergmann suggested 'internet in the sky' - ARINC and Boeing.
Slides that Dock wrote during the discussion are here.
Benefits for users from participation
- better definitions for SLAs
- benefits of critical mass from cooperation
- earlier solution from vendors, using their dollars
- public awareness of the problem, impacting on vendors and the
research community
Benefits for vendors from participation
- better definitions for SLAs
- public relations benefits from participation
- better understanding of issues by users
- opportunity for unusual synergies
- the potential to sell new solutions, or to new customers
Assets
- Membership, and contacts
- OMG partnership
Joe Bergmann explained what he was doing in trying to put together a
network of Universities to work in this space, enabling graduate
students to gain public exposure before leaving University. The
Open Group would offer free membership provided they could support the
travel. We need to talk to DARPA, and there may be research money
available from the 2003 budget in the Critical Infrastructure Assurance
Office.
