The QoSiStates are effectively indicators that a QoSState is operating very close to one of its boundaries, so they may be interpreted as indicators of “negative compatibility”. (However their exact use and interpretation will be application specific.) We show the use of the same q_compatibility and q_time values for the Q_ISCORE as that for Q_SCORE, but different values could be used. Setting lower values for the q_compatibility and q_time for Q_ISCORE would make the AAF more sensitive to operation of a QoSState close to its boundary. This difference between thresholds and timescales between Q_SCORE and Q_ISCORE could, for example, be used to allow fast detection of operation close to QoSState boundaries, while still maintain flow stability when operation is well within QoSState boundaries. Similar application-level smoothing may be achievable by using a large enough value for q_time, but this would then result in lack of responsiveness in adaptability.
6. Discussion
The AAF is the key to the operation of the application. It is the gateway for interaction between the user and the adaptation process of the application. The AAF presented in this paper is mainly to show the use of the SCV/SCV_I information and demonstrate the usefulness of the QoSSpace and QoSState abstractions.
6.1. The QoSStates and QoSSpace
The use of QoSStates simply extends the general information model currently used in methods of describing flow requirements. Flow requirements are often described with performance parameters that must be met in order for the flow to be functional. This is typical for description of resource reservation requirements. However, our treatment assumes that the dynamics, semantics and relationships of QoSStates (inter-flow and intra-flow) are known only to the application. The QoSSpace needs very little semantic knowledge of the QoSStates, and the main requirement is for “low” and “high” to having meaning for QoSParams.
The QoSSpace treats all QoSParams as orthogonal. Each QoSParam is evaluated individually, in the PCVF, and only then is the SCVF for each QoSState evaluated. So, effectively, the treatment of any one of the QoSParams is identical to the treatment of just a single QoSParam. Although in some cases there may be correlation between QoSParams, this is for the application designer to resolve and define QoSStates appropriately, if required. The general model of the QoSState allows the QoSSpace to be applied in a more diverse manner than just in the use of “traditional” QoS parameters. For example, parameters such as battery life, host load and cost could also be used.
The QoSSpace is presented as an abstraction that requires only two pieces of information per QoSParam per flow: an estimate of the current value, p_p, and an estimate of the current variability in that value, v_p. Our simple definition of v_p means that the QoSEngine needs to hold very little historic information for a flow. Additionally, the QoSEngine is separated from the mechanism that is used to provide the values of p_p and v_p. This means that the implementation of the QoSSpace is not constrained. It could, for example, be tightly coupled with the application (embedded), implemented as a kernel module or daemon on a host, or implemented as part of a distributed system using middleware. Also, the nature of this model is such that even if dynamic adaptation is not goal, the use of the QoSStates and QoSSpace may be useful in order to detect per-flow QoS violations from QoS parameter measurements.
6.2. Interaction with the user
The QoS assessment capability offered by the QoSSpace allows daat to adapt to fluctuating network QoS. The decision is made by the AAF and the daat application automatically, but includes (static) user preferences. Another application may be more interactive, letting the user make the decision manually but present the user with a list of options based on the Q_SCORE/Q_ISCORE values or SCVs, allowing the user to make an informed decision.
The AAF is a simple algorithm. The main control issue is the interpretation of the user's wishes, via the user preferences. We have already seen that the QoSSpace has very little semantic knowledge of the flows. Notice that the AAF also has very simple semantic knowledge of the flows in daat. The QoS mapping from the user is simple; better quality QoSStates have higher numbers than lower quality QoSStates. The suitability of use of any particular QoSState is evaluated with Q_SCORES and Q_ISCORES for which “high” and “low” also have meaning. These are the only semantics that the AAF is aware of, making it a simple and easily implemented algorithm. Such simple QoS mapping between user, application and network, coupled with the simple nature of SCVs makes for easy decision-making and easy programmability in real applications. The main aim of the daat examples is to show that the SCVs provided in the QoSReport ease the decision-making process. If simple relationships can be