Lightweight: certain environments are able to support service guarantees such as defined latency and transfer rates. Once these are ascertained an adaptable protocol

may remove unnecessary functions to achieve higher transfer rates.

The Dynamic Reconfigurable Protocol Stack (DRoPS) (Fish et al., 1998) defines an architecture supporting the implementation and operation of multiple runtime adaptable communication protocols. Fundamental protocol processing mechanisms, termed microprotocols are used to compose fully operational communication systems. Each microprotocol implements an arbitrary protocol processing operation. The complexity of a given operation may range from a simple function, such as a checksum, to a complex layer of a protocol stack, such as TCP. The runtime framework is embedded within an operating system and investigates the benefits that runtime adaptable protocols offer in this environment. Mechanisms are provided to initialize a protocol, configure an instantiation for every connection, manipulate the configuration during communication and maintain consistent configurations at all end points. Support is also provided for runtime adaptation agents that automatically reconfigure a protocol on behalf of an application. These agents execute control mechanisms that optimize the configuration of the associated protocol. The remainder of this chapter will address the optimization of protocol configuration. Other aspects of the DRoPS project are outside the scope of this chapter, but may be found in Fish et al. (1998; 1999) and Megson et al. (1998).

12.2 Optimising protocol configuration

The selection of an optimal protocol configuration for a specific, but potentially variable, set of application requirements is a complex task. The evaluation of an appropriate configuration should at least consider the processing overheads of all available microprotocols and their combined effect on protocol performance. Additional consideration should be paid to the characteristics of the end-to-end connection. This is due to the diversity of modern LANs and WANs that are largely unable to provide guaranteed services on an end-to-end basis. An application using an adaptable protocol may manually modify its connections to achieve an appropriate service (work on ReSource reserVation Protocols (RSVP) addresses this issue).

Whilst providing complete control over the functionality of a communication system, the additional mechanisms and extra knowledge required for manual control may deter developers from using an adaptable system. History has repeatedly shown that the simplest solution is often favoured over the more complex, technically superior, one. For example, the success of BSD Sockets may be attributed to its simple interface and abstraction of protocol complexities. Manual adaptation relies on the application being aware of protocol specific functionality, the API calls to manipulate that functionality and the implications of reconfiguration. The semantics of individual microprotocols are likely to be meaningless to the average application developer. This is especially true in the case of highly granular protocols such as advocated by the DRoPS framework. As previously stated, protocol configuration is dependent as much on end-to-end connection characteristics as application requirements. Manual adaptation therefore requires network performance to be monitored by the application, or extracted from the protocol through additional protocol specific interfaces. Both approaches increase the complexity of an application and reduce its efficiency. Finally, it is unlikely that the implications of adaptation are fully understood by anyone but the protocol developer themselves. These factors place additional burdens on a developer who may subsequently decide that an adaptable protocol is just not worth the effort. If it is considered that the ‘application knows best’ then manual control is perhaps more appropriate. However, it is more likely to be a deterrent in the more general case.

It would be more convenient for an application to specify its requirements in more abstract QoS terms (such as tolerated levels of delay, jitter, throughput, loss and error rate) and allow some automated process to optimize the protocol configuration on its behalf.

A process wishing to automate protocol optimization must evaluate the most appropriate protocol configuration with respect to the current application requirements as well as end-to-end connection conditions. These parameters refer to network characteristics (such as error rates), host resources (such as memory and CPU time) and scheduling constraints for real-time requirements. The complexity of evaluating an appropriate protocol configuration is determined by the number of conditions and requirements, the number of states that each may assume, and the total number of unique protocol configurations.

Within DRoPS, a protocol graph defines default protocol structure, basic function dependencies and alternative microprotocol implementations. In practice, a protocol developer will specify this in a custom Adaptable Protocol Specification Language (APSL).

Defining such a graph reduces the number of possible protocol configurations to a function of the number of objects in the protocol graph and the number of alternative mechanisms provided by each. This may be expressed as:

∏

where, F is the number of states of configuration k and k Kthe total number of functions in the protocol graph. The automated process must therefore consider N combinations of requirements, conditions and configurations, which is defined as:

∏

where C is the number of states of condition i and ⁱ R the number of states of requirement^j j, and where I and J are the total number of conditions and requirements. This represents the total number of evaluations necessary to determine the most appropriate configuration for each combination of requirements and conditions. The complexity of this task increases relentlessly with small increases in the values of I, J and K; as illustrated in Figure 12.1.

Part (a) shows the effect of adding extra protocol layers and functions, and part (b) the effect of increasing the condition and requirement granularity.

12.2.1 Protocol Control Model

The runtime framework supports mechanisms for the execution of protocol specific adaptation policies. These lie at the heart of a modular control system that automatically optimises the configuration of a protocol. The methods used to implement these policies are arbitrary and of little concern to the architecture itself. However, the integration of DRoPS within an operating system places several restrictions on the characteristics of these policies.

The adaptation policy must posses a broad enough knowledge to provide a good solution for all possible inputs. However in the execution of this task it must not degrade performance by squandering system level resources. Therefore, any implementation must be small to prevent excessive kernel code size and lightweight so as not to degrade system performance.

Adaptation policies are embedded within a control system, as depicted in Figure 12.2.

Inputs consist of QoS requirements from the user and performance characteristics from the functions of the communication system. Before being passed to the adaptation policy, both sets of inputs are shaped. This ensures that values passed to the policy are within known bounds and are appropriately scaled to the expectations of the policy.

User requirements are passed to the control system through DRoPS in an arbitrary range of 0 to 10. A value of 0 represents a ‘don't care’ state, 1 a low priority and 10 a high priority. These values may not map 1:1 to the policy, i.e. the policy may only expect 0 to 3.

The shaping function normalizes control system inputs to account for an individual policies interpretation.

End-to-end performance characteristics are collected by individual protocol. Before being used by the policy, the shaping function scales these values according to the capability of the reporting function. For example, an error detected by a weak checksum function should carry proportionally more weight than one detected by a strong function. The shaped requirements and conditions are passed to the adaptation policy for evaluation. Based on the policy heuristic an appropriate protocol configuration is suggested.

The existing and suggested configurations are compared and appropriate adaptation commands issued to convert the former into the latter. Protocol functions, drawn from a library of protocol mechanisms, are added, removed and exchanged, and the updated protocol configuration is used for subsequent communication. The DRoPS runtime framework ensures that changes in protocol configuration are propagated and implemented at all end points of communication. The new configuration should provide a connection with characteristics that match the required performance more closely than the old configuration.

Statistics on the new configuration will be compiled over time and if it fails to perform adequately it will be adapted.

Figure 12.1 Increasing complexity of the configuration task.

Figure 12.2 Model of automatic adaptation control system.

12.2.2 Neural Networks as Adaptation Policies

Various projects have attempted to simplify the process of reconfiguration by mapping application specified QoS requirements to protocol configurations. Work by Box et al.

(1992) and Zitterbart (1993) classified applications into service classes according to Table 12.1 and mapped each to a predefined protocol configuration. The DaCaPo project uses a search based heuristic, CoRA (Plagemann et al., 1994), for evaluation and subsequent renegotiation of protocol configuration. The classification of building blocks and measurement of resource usage are combined in a structured search approach enabling CoRA to find suitable configurations. The properties of component functions, described in a proprietry language L, are based on tuples of attribute types such as throughput, delay and loss probability. CoRA configures protocols for new connections at runtime with respect to an applications requirements, the characteristics of the offered transport service and the availability of end system resources. The second approach provides a greater degree of customisation, but the time permitted to locate a new configuration determines the quality of solution found. Beyond these investigations there is little work on heuristics for the runtime optimisation of protocol configuration.

In the search for a more efficient method of performing this mapping, an approach similar to that used in Bhatti and Knight (1998) for processing QoS information about media flows was considered. However, the volume of data required to represent and reason about QoS rendered this solution intractable for fine-grained protocol configuration in an Operating System environment. Although impractical, this served to highlight the highly consistent relationships between conditions, requirements and the actual performance of individual configurations. For example, consider two requirements, bit error tolerance and required throughput, and a protocol with variable error checking schemes. The more comprehensive the error checking, the greater the impact it has on throughput. This is the

case for processing overhead (raw CPU usage) and knock-on effects from the detection of errors (packet retransmission). As emphasis is shifted from correctness to throughput, the selection of error function should move from complete to non-existent, depending on the level of error in the end-to-end connection.

12.2.3 Motivation

If requirements and conditions are quantized and represented as a vector, the process of mapping to protocol configurations may be reduced to a pattern matching exercise. Initial interest in the use of neural networks was motivated by this fact, as pattern is an application at which neural networks are particularly adept. The case for neural network adaptation policies is strengthened by the following factors: