Application adaptation and heterogeneity

In Section 2.5, we talked about getting QoS information from the network, and in Section 2.6 we talked about the need for passive applications that do not use resource reservation, but adapt to network changes based on this QoS information. Once the QoS information has been received, the application must interpret it to make a decision about whether or not it should change its flow-requirement. Such a decision must be made not

only in an application-specific manner, but will be subject to user preferences. However, we can see that the application must somehow determine which of its flow-requirements can be supported by the network given the network QoS information it has, and only then can it make a sensible decision about how to act with respect to the user preferences. When the network QoS is seen to be fluctuating rapidly, the application must be able to make decisions that do not result in “state-flapping” (instability) - any decision making function must be stable with respect to the functionality of the application and the user preferences.

Consider again Figure 2.2. It is unrealistic to suppose that the kind o f detailed a priori information we have about the darhu-theakston path (network configuration, link capacity, knowledge of network traffic) will be available to a user in all circumstances, at all points in the network, and at all times. Certainly this is not true in the case o f the poteen-north scenario. Furthermore, let us consider that the information about the available capacity is to be used by an application to make a decision about how it should behave and operate. Even if such information was readily available a priori for all possible network paths for a user, that user would then need either to make an adaptation decision based on that knowledge or pass that knowledge to the application (somehow) and tmst that the application could make a suitable decision. There are some problems here:

• the user would need to be very knowledgeable to make a sensible decision based on the kind of QoS information that we have presented thus far. Not only would the user require detailed information about the network, but also detailed information about the operation of the application

• even if this first point was true, in a more complex (i.e. realistic) scenario, the user would need to share the network resources on the paths with many other traffic flows. So, there is a strong possibly that there would be many, rapid variations in QoS. The user would need to make many adaptation decisions during the use of the application. Such a process may require much of the user’s time and attention, so we need support for an automatic QoS assessment process that would ease the user’s task or allow the application to make a decision

• there is currently no general model by which the application can come to a decision as such a decision in a particular connectivity scenario can only be achieved by the result of the interaction between user, application and network

The last point is crucial; how can the application make an adaptation decision? One could argue that the application can make the decision based solely on netw ork inform ation as in Scenario lb (Section 1.1). However, consider the case o f Scenario lb or Scenario 2b when different instances o f the application are running over different networks, but are now using different resource reservation schemes or different service-levels, and are controlled by different user preferences. The am ount o f information required to make the adaptation decision is large and complex; it is becoming increasingly difficult for the application to make the decision. This com plexity is evident in the following anecdotal scenario.

W hen the m ultim edia research group at U C L are to have a w ide-area conference across the Internet using tools such as rar [HSK98] and vie#[M J95],they typically spend some time before the conference assessing the netw ork quality and decide which audio encoding to use and the rate o f the video. During the course o f tHe coiiference, there will be som eone at many (som etim es each) o f the conference sites rnonitoring the conference quality. These people will com m unicate out-of-band in order to m ake co-ordinated adjustm ents to the operation o f rat and vie as the quality changes (e.g. change the audio encoding or drop the video so that the audio can continue at reasonable quality).

There are three key points in this scenario:

1. the decision as to how to adapt is made through the expert know ledge and experience o f the users

2. the decision making process requires all participating sites to com e to the same decision, i.e. they have the same expertise and knowledge (“same algorithm ” )

3. the tools themselves rely on the humans to make the m ajor decisions about the state o f the applications (user preferences)

In this chapter, we have noted that there are m echanism s that may aid the application in obtaining information about the QoS offered by the network for a particular flow, as well as allowing the application to request QoS guarantees from the network. How ever, in the face o f heterogeneity, it is still very hard to enable the application to make dynam ic and autom atic QoS assessments, or allow the user to make an inform ed change o f user preferences. There is no capability that allows assessment o f all the QoS inform ation available to the application. W e need to offer the application a m echanism that provides a suitable QoS information summary that allows it to dynam ically m ake an assessm ent of

how it should adapt. It may then be possible for it to interact with the user in order to change flow-requirement or mode, or even make an adaptation decision automatically.