Charter

The main objective of this design group is to help acquire a better understanding of QoS needs that advanced Internet2 applications exercise, by using Internet2 infrastructure and its advanced capabilities. In other words this design group would be an interface between application people and networking people, helping both to reach better common understanding of the QoS requirements of various applications and how those requirements could be met using new network services that are provided (or could realistically be provided) in Internet2 environment.

In particular these activities will include, but will not be limited to:

• Survey of research: provide a survey of research that is aimed towards identifying the minimal and best values of the system parameters that play important roles in application level quality measure. In other words, by knowing the values of the system parameters that influence human perception we would be able to have the best guess about the bandwidth, burstiness, loss of data, delay and jitter that will be expected as deliverables from the networks. For example, VR applications use the term "presence", which can be regarded as a subjective and objective measure of QoS in application domain. If smaller than minimal values in an application domain these parameters contribute towards a break of presence, i.e., downgraded QoS. Examples: low video frame rate, excessive loss of data (audio, navigation).

• Application needs for QoS:

  • study and identify the needs of different categories of Internet2 applications, starting with applications that need absolute assurance for particular QoS parameters (bandwidth, loss, delay, jitter) and moving towards the category of applications that can require differentiated classes of service. This would in particular mean supporting studies in this area, in the sense of helping CS researchers obtain access to Internet2 infrastructure/measurements if it would further their research agendas and analysis.

  • study and identify the needs of applications that operate with a plethora of sensory information simultaneously (2D and 3D video information, audio, haptics-touch, force feedback, smell, variety of position/navigation information like in headtracking or bodytracking systems). Applications with multiple related QoS-needy streams would be encouraged and supported in exploring different QoS trade-offs in order to preserve overall system requirements.

• Guidelines for application and middleware developers: develop the guidelines to help application and middleware developers configure the services they want to request from the network.

• Monitoring and assessment tools: foster the development and deployment of tools that help monitoring and assessment of the QoS provided. In that way the group would contribute towards the design of the Internet2 measurements infrastructure. These tools could be used in conjunction with both simulation tools and the QoS application testbed (below). The group would also consider establishing a permanent application-level measurement infrastructure.

• Simulation tools: foster the development and deployment of the tools that would mimic demands that applications pose to the network, simulating deployment of QoS solutions and obtaining real network response. These tools would provide an early testbed and could be used and studied independently from the real applications. Note that this should not be understood as a replacement for experience with real applications and real situations, but only as a useful step before we are in a situation to deploy QoS solutions into real applications.
  (These tools will be extremely important to have in cases where an application is not available yet (i.e., it is still not implemented), or it is not robust enough to run desired variety of QoS tests. Also, these kinds of applications engage multiple sites and infrastructure/ equipment, and organizing and managing collaboration of such a large and diverse group might result in insufficient number and variety of tests.)

• QoS application testbed: select and partner with a small number of Internet2 application initiatives, supporting them to using and evaluate current QoS solutions, monitoring their network activity and working together with them on identifying new QoS services that might appear needed.

• New QoS services: working with simulation tools and QoS application testbed initiatives, identify whether proposed network services are adequate to meet the needs of applications or some new services should be defined. In the latter case the group would define the guidelines for the implementation of new QoS services, having in mind existing or potential users of those services primarily rather than constraints on the network level.

• Reference information and help: build and maintain a set of web pages that would give a variety of important information to application and middleware developers: points of contact for different issues (connectivity, tools available, different initiatives in QoS space); lessons learned, "tips and tricks"; pointers to related sites, events, literature; organize discussion forums.