Distributed multimedia applications have dierent quality of service (QoS) requirements

Transcription

1 Automatic Generation of Dynamically Adaptable Protocols R. de Silva L. Dairaine A. Richards A. Seneviratne M. Fry 29th May 1995 University of Technology, Sydney School of Electrical Engineering P.O. Box 123, Broadway NSW 2007 Australia Abstract: Distributed multimedia applications have dierent quality of service (QoS) requirements from the simple reliable data transfer QoS provided by transport protocols like TCP and TP4. New protocols can be created to handle some of the general QoS requirements of distributed multimedia applications although this is a costly process in terms of time and money. In addition, given the variety of dierent multimedia applications and their dierent requirements, hand-crafting tailored protocols is not a viable approach for the future. A solution to this problem is to automate the process for protocol generation. This paper examines and contrasts two relevant models of automatic protocol generation, namely stub compilation and runtime adaptive approaches. Then, a new model based on the combined strengths of the previous approaches is introduced. The proposed model envelopes concepts like application layer framing, integrated layer processing and dynamic adaption of functionality. Keywords: Tailored Protocols, Transport Protocols, Application Layer Framing, Integrated Layer Processing, User level protocols. 1. Introduction In the seventies and early eighties, transport protocols such as TCP and TP4 provided functionality for applications running over unreliable networks. The main requirements of those applications were to be able to reliably transfer data across the network. Given the highly unreliable nature of the networks then, the transport layer provided functionality to hide the errors of the underlying network from the application. Today, applications have new sets of requirements. These requirements are not constant and vary depending on the applications and the media they support. In addition, underlying networks now provide faster and more reliable services than before. The result of these changes

2 2 R. De Silva L. Dairaine A. Richards A. Seneviratne M. Fry is that classical protocols are neither able to satisfy the requirements of the applications nor properly use the services provided by the network. Therefore, it is necessary to develop new protocols that are able to handle the new requirements of applications while optimizing the use of the services provided by the underlying network. Given that dierent applications may have suciently dierent requirements this would mean that to achieve maximum benets, each application would require its own protocol. This is a very time consuming problem. One solution to this problem is to automate the creation of protocols according to a given set of application requirements. This paper looks at two such automated models INRIA's stub compiler model and Sydney's University of Technology's runtime adaptive model. The two models are discussed and contrasted before dening a new model based on the strengths of two previous approaches. The proposed model for automatically generating adaptable protocols, integrate concepts of application layer framing, integrated layer processing and dynamic adaptation which are only partially supported in the previous models. The rest of the paper is structured as follows: section 2 discusses important factors relevant when designing protocols for high speed environments. Section 3 shows the basic concepts of automated protocol generation. Section 4 and 5 look at the stub compiler and runtime adaptive models. Section 6, will introduce the new model. Concluding remarks are presented in section Tailoring Protocols in High Speed Environments Classical protocols like TCP and TP4 have been shown to be a bottleneck in the communication system when used over high speed networks [9, 12, 18]. A number of dierent solutions have been proposed to solve the problems of these protocols. The proposals can be placed into two main categories. One suggests that classical protocols can be made more suitable by applying some simple optimizations to the protocol implementation [7]. The second group proposes the design of new protocols [20, 8, 5]. Optimizing the protocol implementation, especially the critical path of execution improves performance of the protocol [21]. This however does not address one of the major problems of current protocols, namely the functionality used is unsuitable to certain applications. For example, the ARQ error recovery schemes are unsuitable for most real time data transfers and normally will only increase the end-to-end delay of the connection [11]. Thus optimizations to the implementation fail to solve problems resulting from functionality supported by the protocol. Then the alternative is to create new protocols, adapted to the application characteristics and underlying network. In the process of tailoring a protocol to an application, there are three basic concepts that should be applied, namely protocol function selection, implementation optimizations and dynamic protocol conguration Protocol Function Selection The rst concept is to choose appropriate functionality for the given application requirements. This involves choosing the appropriate functionality as well as the appropriate mechanism.

3 Automatic Generation of Dynamically Adaptable Protocols 3 The table below summaries some of the functionality that could be used and some of examples of mechanisms associated with them. Application Requirements Functionality Mechanism Error Detection Sequence Detection Sequence Number Parity based CRCs Odd, Even, BCC, Checksum Various Polynomials Error Recovery ARQ Variation of Go-back-N, Selective Repeat Forward error recovery Hamming, Reed Solomon Codes Flow & Congestion Control Sliding windows Fixed size, Variable size, Slow start Rate control Leaky bucket, gapping Connection Setup Explicit 3-way, 2-way handshakes Implicit Connectionless, First packet Connection Closing Explicit 2-way handshake Implicit Timer mechanism Table 1: Protocol Functionality and Mechanisms. Note that the selection of protocol functionality can overlap. For example, if sliding windows was chosen for ow control then the same mechanism should be used for detecting sequencing errors. It is also important to recognise that none of the above functionality are mandatory. For example, UDP could be considered to only support optional error detection using checksums and none of the other functionality Implementation Optimizations The second concept involves using implementation optimisations like Application Layer Framing (ALF) and Integrated Layer Processing (ILP)[6]. Application layer framing involves designing the application to send self-contained blocks of information to the communication system. This means that this block can be sent to the receiving application which can proceed to process the block of information without knowledge of the previous or next blocks of information. This allows for faster processing of information as the application does not have to wait for packets and also allows for better use of system resources. Integrated layer processing is a method of increasing the cohesiveness of the application and communication system to improve the implementation [6, 1]. ILP involves grouping byte operations that are done at various layers of the communication system and combining them. An example of this is to combine presentation layer processing like XDR with checksum calculations at the transport layer.

4 4 R. De Silva L. Dairaine A. Richards A. Seneviratne M. Fry 2.3. Dynamic Protocol Conguration The nal concept that is can be in improving performance of the transport protocols especially in regard to the underlying network is dynamic adaption of protocol functionality. It has shown in [15] that it is possible to dynamically remove and add protocol functions at runtime to improve the performance of the application and the transport protocol. An example would be that due to a failure with a terrestrial link, the data is redirected through a satelite link. As a result of the increased end-to-end delay, it may be ecient to dynamically change the error recovery mechanism of a protocol from go-back-n to FEC. Although the example of the dynamic protocols given are based on changes at the network layer, this concept could just as easily be used for changes in the application layer. It is important to note that there has to be a mechanism for detecting when the changes that should take place and a mechanism for handling the end-to-end mechanism adaptation. Although these three concepts can be applied to develop new protocols tailored to a given application, the main problem is this new protocols will be very likely unsuitable for a second application. This results with a new protocol being developed for each application or application class which is very costly. Moreover, the implementation of these concepts are not simple an hence would require highly skilled personnel. The proposed solution for this problem is to automate the generation of protocols given an application specication. 3. Automated Communication Protocol Generation Automated tailored protocol generation can be achieved by dening, for a given application, the functionalities the protocol should provide and the associated mechanisms. As illustrated in gure 1, the overall process involves three basic tasks: 1. Specication: How to specify the application's requirements, and the system and network characteristics; 2. Selection: How to select the right mechanisms according to the application needs; 3. Synthesis: How to generate and implement the tailored communication subsystem. The specication of the application forms the rst phase in the automated process. The specication should contain all the revelant information needed by the automated process to create the appropriate tailored protocol. The specication should therefore include information on the structure and characteristic of the data to be transfered. This includes information about the possibilities of having self contained data packets (based on ALF principles), temporal constraints of the data and possible ranges for acceptable performance criteria (i.e., throughput, delay, jitter, etc.). Also, to include integrated layer processing, the automated process requires knowledge of any processing done on the data so that it can, where possible, be combined these to the main communication processing loop. Network and system information may also form part of the specication. The specication phase determines the quality of the tailored protocol.

5 Automatic Generation of Dynamically Adaptable Protocols 5 Application Requirements Specification Network & System Characteristics Automatic Protocol Generator Selection Synthesis Tailored Protocol Protocol Functions Figure 1: Automated protocol building scheme. The selection of mechanisms is the second phase of the automated process. Using information that characterizes the application, the Automatic Protocol Generator (APG) decides the overall functionality required to build the tailored protocol. If the protocol is intended to be dynamic then decisions of when to switch protocol functionality can be decided at this stage of the APG. Finally, the synthesis phase involves the implementation of the protocol. It has been shown that for ecient implementations integrated layer processing (ILP) [6] should be adopted. The implementation can be static or dynamic. Dynamism can be implemented by using dynamic linking of protocol functions as required or statically implemented in a state machine which changes states when changes in protocol functionality is required. The latter can result in code bloat if a large number of dynamic states are dened. An important feature of APGs is that it is not viable to create tailored protocols at the kernel level for two reasons. Firstly, because a tailored protocol is designed for one application and the kernel should oer common services to all applications. Secondly, recompiling the kernel for each new application created is a time consuming process. And given that tailored protocols have to be created for specialized applications, they should be done at the user level. Maeda has shown that such a user level protocols does not detract from the performance of the implementation [14]. A number of automated approaches have been proposed such as: 1. Da CaPo [19]: a congurable protocol allowing the ordering of protocol functions using dependency graphs; 2. F-CSS [22]: a exible protocol stack aimed at parallel implementation; 3. ADAPTIVE [17]: a dynamically assembled protocol transformation, integration and validation environment; 4. Runtime Adaptive Approach [16]: a dynamically congurable approach based on a library of protocol functions;

6 6 R. De Silva L. Dairaine A. Richards A. Seneviratne M. Fry 5. Stub compiler [3]: a static model based on the use of Esterel to create tailored protocol. The rst four models provide runtime conguration while the fth model only provides compilation time conguration. The two next sections of the paper will give detail on the two last approaches, namely Stub compilation and runtime adaptive approaches. These two model have been selected to contrast the runtime and compilation approaches. 4. Stub Compilation approach The stub compilation approach has been developed at INRIA (Institut National de la Recherche en Informatique et Automatique) in France. This approach is a preliminary step in the design of a new generation of remote procedure call models [10]. In this model, a distributed application can specify its own communication requirements to be associated to a dedicated communication protocol. This is realized by a means of an application specication used by the protocol compiler to integrate communication facilities to the application and to generate the client and server stubs. The implementation of the protocol compiler is based on the use of Esterel, a imperative language belonging to the family of synchronous reactive formalisms [2]. The language was selected for numerous reasons [3]. Firstly, Esterel provides only for the description of the control part of the protocol. This feature creates a strong separation between specication and implementation issues. Due to its properties of synchronicity it is particularly appropriate for the description of communication protocols. Moreover, it can be eciently combined to a data description language. Finally, the environment provided with Esterel is complete and ecient (both a development and a validation environment are available). As illustrated in gure 2, the stub compiler model includes the three main steps for the generation of a tailored protocol, namely specication, selection and synthesis. The specication step is achieved using both Esterel and C code. Esterel species the control and synchronization aspects of the application, while data structures and application software are directly coded in C. More specically, the Esterel specication describes the application's behavior, and the level of reliability required for the transmission of the Application Data Unit 1. The level of service required is described by a set of predened Esterel signals expressed in the specication, such as selective_retransmission, ow_control, checksum, etc. Then, the selection step is realized through the parsing of the specication [10] as shown in gure 2. From the Esterel description of the application's behavior, the parser extracts possible synchronization points and any parallelism that exists between the dierent modules that compose the description. These synchronization points will be used in the synthesis stage to design the most ecient implementation. The predened Esterel signals present in the application specication are extended by the parser to integrate the requested communication facilities. The result of this step is the integrated specication, still expressed in Esterel. The new Esterel specication is then compiled through a Esterel compiler [2] [4] which produces C-code for a nite state machine dening the dierent protocol states. This C-code is then combined with the appropriate application code and the appropriate protocol functions 1 The smallest unit of data that the application can handle on its own, i.e., ALF

7 Automatic Generation of Dynamically Adaptable Protocols 7 User specification Application Specification in Esterel Application Software in C Data Structure Description in C Parser Protocols & Functions Specification in Esterel Compilation Processes Integrated Specification in Esterel Esterel Compiler Integrated Source in C Protocol Functions in C C Compiler Tailored Protocol Figure 2: The Stub compiler model. to create the executable application. The C and Esterel compilers form the implementation stage of the APG model. The main strength of the stub compiler model is that it provides a high degree of tailorability. The main reason for this is the use of Esterel, a formal language, which allows for an accurate description of the application's requirements. The stub compiler model can handle application layer framing. The model could be extended to incorporate ILP by passing information about the application processing loops to the Esterel compiler. If the Esterel compiler integrates the combined code of the Esterel specications, application and protocol functions then it could apply ILP concepts in the implementation it creates. One weakness of this model is that the stub compiler model is based on a state machine which changes state to provide dierent services. Therefore if ILP were carried out, it could have to be done on each of the states and might result in a code bloat if a large number of states are dened. Currently, this model does not properly consider dynamic adaption as it fails to take into consideration external factors such as network and system loads.

8 8 R. De Silva L. Dairaine A. Richards A. Seneviratne M. Fry 5. Runtime adaptive approach The runtime adaptive approach has been developed at UTS (University of Technology, Sydney) in Australia [15]. As shown in gure 3, the conceptual architecture of the runtime adaptive model follows the general view of tailored protocols. User Specification Application Application Needs Runtime Adative Processes Network Status System Load Functionality Selector Profile Synthesis Engine Protocol Functions Library Implementation Techniques (e.g., ILP) Tailored Protocol Figure 3: The runtime adaptive model. The functioning of UTS follow the 3 classical phases: 1. Specication: at runtime, the application indicates its requirements to the Functionality Selector, for example via a QoS management entity. 2. Selection: the Functionality Selector then determines the protocols functions that will be required to satisfy the application's requirements. A prole is then generated that indicates to the Synthesis Engine, the optimal choice. 3. Synthesis: the Synthesis Engine the takes into account the environment status (i.e., network status and system load) and chooses the appropriate mechanisms to provide the requested functionality. It then uses optimized implementation techniques such as ILP to implement the transport system. In addition, the Synthesis Engine continuously monitors the status of the network and host system and, where possible, dynamically chooses the algorithms that will best suit the given conditions. The library based model diers most from the compiler based model, in its inherent dynamicity. The conguration engine creates/modies the protocol as necessary due to the

9 Automatic Generation of Dynamically Adaptable Protocols 9 changes in any of its inputs (network status, prole). Dynamicity is achieved by dynamically linking in and out the appropriate protocol functionality as determined by the Synthesis Engine. Like the compiler model, the adaptive approach takes into account ALF and ILP principles although this model does not totally handle the problem of ILP. Since the protocol is dynamic which requires the inclusion and removal of protocol functionality, it is dicult to apply principles of integrated layer processing which are optimizations naturally based for static implementations. If we look at each model and try to determine the most important process of the model - for the INRIA model it is based around the Esterel compiler to create the best tailored protocol while with the runtime adaptive model it is based on the synthesis engine. 6. New Dynamic Model The suggested model, depicted in gure 4, is primarily an extension to the runtime adaptive model. The model includes the concepts of the stub compiler model in that the specication analyser basically can be represented by the parser and the synthesis engine by the Esterel compiler stages of the stub compiler approach. Although, it should be noted that the output of the Esterel compiler would dier for this model than that of the stub compiler approach and as such this representation has not be shown in the model to prevent confusion. The model consists of three main processes - the specication analyser, the compiler and the synthesis engine. The model proposed, like the runtime adaptive model, is dynamically recongurable. When dealing with dynamic models there are two stages at which decisions on protocol functionality are made. The rst one is during compilation time, when decisions about application layer framing and stages of data transfer are realized. The second one is during runtime, when the inuence of the underlying network and system loads aect the performance of the protocol. This model is then divided into two main sections : the ALF processes or compilation processes (the specication analyser and the compiler) and the ILP processes or runtime processes (the conguration engine and the tailored protocol) The Compilation Processes This stage of the APG model basically results in an executable which consists of the application and a conguration engine. There are three main inputs into this section the application code, the application specication and the conguration engine code. The specication should contain information to aid the conguration engine with deciding the appropriate functionality. This information can be specied using three methods: Request direct functionality - Here the application directly requests the functionality it needs or the specic method of providing functionality (see table 1). This method reduces the decisions made by the conguration engine but can be restrictive as changes due to network or system load will not be able to modify this functionality.

10 10 R. De Silva L. Dairaine A. Richards A. Seneviratne M. Fry User specification Application Specification Application Code Compilation Processes Specification Analyser Profile Compiler Synthesis Engine Code Protocol Functionalities Runtime Adaptive processes Application Structure Application User Interface Network Status System Load Synthesis Engine Tailored Protocol Protocol Mechanisms Figure 4: The new dynamic model. Provide requested QoS only - This allows for maximum exibility as the conguration has only to satisfy the requested QoS for the data transfers. The main disadvantage of this method is the large amount of decisions that have to be made by the conguration engine due to the large number of combinations. Combination - Here the application request functionality but species that if certain QoS parameters are not met then the functionality can be changed. Suggested changes can also be provided. For example the application may request error control but specify under certain conditions that this functionality may be removed. The specication should also contain information about any processes that can be included into an ILP loop by the conguration engine. Finally the specication should have any information about any ALF handling done by the application so that the tailored protocol and provide appropriate support functionality. The specication in processed by the specication analyser to produce a prole of the application. As previously mentioned, the specication analyser can be compared to the Esterel compiler and parser of the stub compiler approach. The prole, the application code and conguration engine code is then compiled to produce the application with the conguration engine for the tailored protocol.

11 Automatic Generation of Dynamically Adaptable Protocols The Runtime Adaptive Processes The conguration engine dynamically links in the appropriate protocol functions based on decisions made based on the prole of the application. The conguration has then three main functions that it has to do - monitor for any conditions that would require changes in protocol functionality; when necessary make decisions on what protocol functionality to support and to carry out ILP processing for the chosen functionality. This can be represented by gure 5. Synthesis Engine Monitor Decision Engine ILP Processor Figure 5: Synthesis Engine Processes Conguration Engine Monitor The conguration engine monitors checks for conditions that could results in changes to con- guration of the tailored protocol functionality. There are three conditions that could result with the change of protocol functionality : Changes in State of Data Transfer - Some forms of data transfer have dierent requirements for dierent stages of transfer. These changes in state are at xed positions of the transfer and these positions will be decided in the application specication. Changes from User Interface - Users may request changes in the underlying service through the interface. For example the user may change from browsing to recording a video le from a server thus changing the QoS requirements of the data. The main problem caused by this condition is that it can occur at any point during the data transfer. Changes caused by Network or System Load - Network and system load conditions may prompt the conguration engine to change the functionality of the tailored protocol to improve performance. These three factors are represented in the model as inputs into the synthesis engine. The synthesis engine will rstly attempt to solve any problems caused by these changes internally. If it fails to resolve any conicts then it will request help from the user, similarly to how disconnected operations are handled in the Coda [13] le system.

12 12 R. De Silva L. Dairaine A. Richards A. Seneviratne M. Fry Decision Engine The decision engine bases decisions on two sets of rules. An internal set of rules based on the dierent characteristics of the protocol functionality supported and external information provided by the application prole. The latter is given precedence when decisions are made ILP Processor The ILP processor attempts to combine the protocol functionality chosen by the decision engine into an ILP loop to improve the performance of the tailored protocol. Any external application processes specied in the prole would also be included in this loop. Integrated layer processing concepts are complicated again for this model as they are being applied as optimizations to a dynamic system and at runtime. 7. Concluding remarks In this paper, we have introduced a new model for the automatic generation of dynamically adaptable protocols. The model was based on a study of two approaches, namely stub compilation and runtime adaptive approaches. The approach can be divided into two main set of processes the compilation processes and the runtime processes. Compilation process takes into account an application specication to create a synthesis engine tailored to the application requirements. The runtime processes include the synthesis engine which dynamically congurates a tailored protocol depending on various external triggers. The separation of the compilation and runtime processes allows for the accurate specication of an tailored protocol while achieving all the benets of dynamicity and adaption. We are currently designing and implementing a prototype implementation of the proposed model. 8. Acknowledgments Laurent Dairaine thanks INRIA from its the nancial support. Anthony Richards acknowledges the support from Telecom Australia. Aruna Seneviratne acknowledges the support from the UTS Internal Grants Scheme. References [1] M. Abbott and L. Peterson, Increasing network throughput by integrating protocol layers, IEEE/ACM Transactions on Networking, 1 (1993), pp ftp://cs.arizona.edu/xkernel/. [2] G. Berry, The Esterel synchronous programming language: Design, semantic, implementation, Journal of Science of Computer Programming, 19 (1992).

13 Automatic Generation of Dynamically Adaptable Protocols 13 [3] C. Castelluccia, I. Chrisment, W. Dabbous, C. Diot, C. Huitema, E. Siegel, and R. de Simone, Tailored protocol development using ESTEREL, Research Report 2374, INRIA, 2004, route de Lucioles, B.P. 93, Sophia Antipolis cedex, France, Oct [4] C. Castelluccia and W. Dabbous, Modular communication subsystem implementation using a synchronous approach, internal report, INRIA HIPPARCH Project, 2004, route de Lucioles, B.P. 93, Sophia Antipolis cedex, France, [5] G. Chesson, Protocol engine design, in Usenix Conference, Amsterdam, June 1987, pp [6] D. Clark and D. Tennenhouse, Architectural considerations for a new generation of protocols, in Proceedings of ACM SIGCOMM Conference (Communication Architecture and Protocols), USA, 1990, pp [7] D. D. Clark and H. S. V. Jacobson, J. Romkey, An analysis clark of tcp processing overhead, IEEE Communication Magazine, 27 (1989), pp [8] A. Danthine, Esprit project osi 95 new transport services for high-speed networking, in 3rd Joint European Networking Conference, Innsbruck, May [9] A. Danthine, B. Hauzeur, P. Henquet, C. Constantinidis, D. Fagnoule, and V. Cornette, Corporate communication system by LAN interconnection, in EURINFO Information Technology for Organisational Systems, E. N. Holland), ed., Athen, May 1988, pp [10] C. Diot, I. Chrisment, and A. Richards, Application level framing and automated implementation, in IFIP HPN international conference, Sept [11] J. Harju, V. Kosonen, and C. Li, Quality and performance of a desktop video conferencing system in the network of interconnected LANs, in In 19th Conference on Local Computer Networks, [12] S. Heathley and D. Stokesberry, Analysis of transport measurements over a local area network, IEEE Communication Magazine, 27 (1989). [13] J. J. Kistler and M. Satyanarayan, Disconnected operation in the coda lesystem, ACM Transactions on Computer Systems, (1992). [14] C. Maeda and B. Bershad, Networking performance for microkernel, internal report, Carnegie Mellon University, School of Computer Science, Carnegie Mellon University, Pittsburgh, PA 15213, USA, Mar ftp://mach.cs.cmu.edu/doc/. [15] A. Richards, The Universal Transport Service, an Adaptive End-to-end Protocol Analysis and Design, ph.d. thesis, University of Technology, Sydney, Department of Electrical Engineering, P.O. Box 123, Broadway, NSW 2007, Australia, Dec ftp://ftp.ee.uts.edu.au/pub/prose/.

14 14 R. De Silva L. Dairaine A. Richards A. Seneviratne M. Fry [16] A. Richards, T. Ginige, A. Seneviratne, T. Buczkowska, and M. Fry, An adaptive transport service suitable for high speed network, The Journal of Concurrency: Practice and Experience, (1994). ftp://ftp.ee.uts.edu.au/pub/prose/. [17] D. Schmidt, D. Box, and T. Suda, ADAPTIVE: A exible and adaptive transport system architecture to support lightweight protocols for multimedia applications on high speed networks, in Proceedings of the Symposium on High Performance Distributed Computing Conference, Amsterdam, Sept [18] L. Svodobova, Measured performance of transport service in LANs, Computer Network and ISDN Systems, 18 (1989), pp [19] M. Vogt, B. Plattner, T. Plagemann, and T. Walter, A runtime environment for Da CaPo, in INET, [20] A. C. Weaver, Making transport protocols fast, IEEE, (1991). [21] C. Woodside, K. Ravindran, and R. Franks, The protocol bypass concept for high speed OSI data transfer, in IFIP WG 6.1/WG 6.4, Amsterdam, Nov. 1990, North-Holland Publisher, pp [22] M. Zitterbart, B. Stiller, and A. Tantawy, A model for exible high performance communication subsystems, IEEE Journal on Selected Areas in Communications, 11 (1993), pp