HIPPARCH aims at investigating novel architectures for high performance communication protocols based on the Application Level Framing (ALF) and Integrated Layer Processing (ILP) concepts [CT90].

In a nutshell, ALF states that applications should organize the data they are sending as a sequence of autonomous "frames", which will be at the same time the unit of transmission, the unit of control and the unit of processing. This allows for efficient design of application specific protocols since each frame is self contained. It also enables the integration of layers, ILP, for more efficient processing. With ILP, the number of time consuming references to primary memory in modern fast processors can be reduced by integrating data manipulation functions into one or a few loops.

ALF will enable efficient design of application specific protocols for heterogeneous networks (like the Internet), integrating controls tuned to the applications needs and adaptation algorithms for the best utilisation of available network resources.

In the HIPPARCH LTR project we propose to extend the research initiated with HIPPARCH EC­AUS activity (where ALF based designed has been validated) to the broadest possible range of information services and applications. We will study the benefit of the ALF and ILP principles for the design of communication systems supporting multicast, mobility, and real­time media. The expected main results are:

• A protocol compiler to be made available to partners, other research groups, and industry.
• Specific control algorithms for unicast, multicast and "network conscious applications" mixing real­time and non real­time data transfers.
• An execution environment which supports real time protocol implementations.

A relevant multimedia application consisting of architecturally enhanced WWW client and server will be developed to demonstrate the project results. The application will show the viability of the compiler and the performance of the adaptive protocols and control algorithms. The application and the protocols will be used over heterogeneous high speed, mobile and wireless networks. The project results will be distributed to and actively discussed with standardization bodies by project members or supporting industry participants for future standard protocols and architectures.

The project has industrial partners which manufactures mobile communication equipment, provides network information services and builds safety critical real­time distributed systems. This will ensure the take­up of results directly by industry and to give them a competitive advantage in producing efficient application specific protocols for the networked society. The project partners are: the "Institut National de Recherche en Informatique et en Automatique" (INRIA, France) project coordinator, Dassault Electronique (DE, France) industrial partner and technical coordinator of the project extension, Uppsala University (UU, Sweden), Swedish Institute for Computer Science (SICS, Sweden), University College London (UCL, United Kingdom). Two major European companies: British Telecom (BT, United Kingdom) and Ericsson Radio AB (ERA, Sweden) will participate in the steering committee of the project. University of Technology, Sydney (UTS, Australia) will have a scientific collaboration with the project members (this collaboration is not funded by EC).

HIPPARCH aims at investigating novel architectures for high performance communication protocols based on the Application Level Framing (ALF) and Integrated Layer Processing (ILP) concepts developed at MIT [CT90]. We build upon the results of the HIPPARCH EC­AUS activity, during which we developed a prototype compiler, application protocols and network APIs based on ALF. ALF means that the application data unit (ADU) is also the data unit used for transmission and for control. If the transmission unit is not the same as the unit of control, the result is unnecessary large retransmissions in case of errors. Also, if the application and transmission units are not the same, ADUs must be reassembled before being delivered to the application. This will unnecessarily delay application processing, because received data units are held in the reassembly buffer until a complete ADU is received. For example, an image server will send messages corresponding to well identified parts of the picture. When a receiver receives such a frame, it can immediately decompress the data and "paint" the corresponding pixels on the screen, thus minimising response times, instead of queuing it waiting for other parts.

Through some initial experiments with multimedia services in the HIPPARCH EC­AUS activity, we found that adaptive applications are much easier to develop if the unit of processing is also the unit of control, as well as the unit of transmission. As each frame is autonomous, all data manipulations relative to various layers of protocols can be performed in one or a few loops, following the ILP model. This can reduce the number of transfers of the data between main memory and the processor. This is a major bottleneck in modern computer systems, where the processor is much faster than the access rate of the main memory. However, this collapsing of functions to a loop has its own drawbacks. In short, it may result in very complex code. Therefore, we intend to provide these services in a protocol compiler. ALF supposes that the network transmits the data as application frames. Many networks have large enough packets to carry these frames while others may need some framing protocol. For example, AAL5 can be used on ATM channels and PPP or HDLC on other small packet networks, such as wireless networks.

The approach in the HIPPARCH LTR project is described below.

The traditional empirical methodology to produce communication software is mostly "intuition based on experience". It will not be able to scale up effectively and to produce highly integrated implementations for the new generation of applications. To be able to design communication systems tailored to application characteristics, the development process should be largely automated in a formal framework. A formal automated design process also allows the correctness of the communication to be checked both in terms of reliability and security. The HIPPARCH EC­AUS activity provided an initial demonstrator of the Protocol Compiler, which we want to further develop during HIPPARCH LTR project. The Protocol Compiler intends both to validate the introduction of formal description techniques and to evaluate integrated communication systems architectures.

The Protocol Compiler of the HIPPARCH LTR project (called ALFred) will integrate transmission control facilities to the application formal specification, and then generate an ILP communication system for distributed execution purpose.

We anticipate that applications will have to adapt to variable networking environments, e.g. very high speed ATM links, conventional digital connections, and relatively low speed mobile networks. We propose to develop "network conscious" applications and protocols that adapt automatically to these environments. They can either send only the most significant data when the bandwidth is scarce, or provide the users with a full service when the bandwidth is plentiful. ALF seems to be very useful for such designs. Different applications require different algorithms: the "most important" signals are not extracted in the same manner from an audio stream and from a text document. We will develop and document algorithms for both classic applications, and also for the real time multicast of multimedia streams. The latter will be proposed as an evolution of the IETF's "Real­time Transport Protocol" (RTP). RTP is already based on the ALF principles. INRIA, SICS and UCL were partners in the MICE project (ESPRIT) and already have experience with RTP and adaptive multi­media applications. We can also integrate in this fashion "real time conferencing", when the documents are created in real­time and multicast to several users simultaneously.

The protocol implementations generated by the compiler will need services common to all protocol processing such as buffer management, event handling, and interfaces to host operating system/hardware. We call these services the protocol support environment. In the HIPPARCH EC­AUS activity, we focused on how to provide an efficient buffer management for ILP/ALF protocols [AG94]. In the HIPPARCH LTR project we will expand this environment with real time services for new time­constrained applications, like multimedia. We will also provide mechanisms for scheduling communication resources in order to provide predictable delay, application­to­application.

We propose an integrated, holistic approach for scheduling the resources, to do a one­to­one mapping of "network flows" to end system threads. It will build on previous research done separately on real time threads and research on network resource reservations such as RSVP and flow management. We believe that ALF is beneficial for a holistic scheduling since appropriate resources can be directly associated with an arriving frame.

We will illustrate our approach by proposing a core experiment, based on the World Wide Web, that will provide a show­case for all of the project results. The World Wide Web is based on the tried and trusted Client/Server model. In a typical WWW access, the client sets up a TCP/IP connection with the server, sends a document request and get back a Mime encoded content. Then, if the data includes in­lined references to other objects, the client either retrieves each part in turn, which generates long delays, or retrieves several documents in parallel, which increase the instantaneous load at servers and is somewhat unfair.

Due to TCP congestion control, whoever use more connection gains an undue advantage. In any case, multimedia documents containing audio and video segments have to be entirely transmitted and stored on the local disk before these documents can be presented to the user, which can result in very long delays.

We propose to demonstrate the benefits of the ALF architecture by designing a UDP based version of the HTTP protocol. Replacing TCP­IP by a combination of UDP and appropriate

Controls integrated in the application will:

• allow out of order processing of packets, speeding up its display,
• allow selective retransmission, for a more efficient error control,
• allow real­time rendition of audio and video documents,
• allow servers to control the resources allocated to various users, implementing explicit classifications and fairness control policies.

We will demonstrate ''network­consciousness'' by running the WWW client over a variety of networks, such as GSM links, packet radio networks, standard LANs and ATM channels.

The demonstration will be comprised of two parts firstly the WWW client and server will be designed and hand built, the output from this process will be used to produce a specification which can be used to automatically generate a WWW client and server. The performance of these two sets of applications will then be compared.

The results of the previous experiments lead to investigate more deeply some elements of the Hipparch architecture. They also lead to investigate the promising techniques that could be integrated rapidly in commercial offers or, at least, be experimented in new Internet platforms.

The first work-packages demonstrated the necessity of flexible and efficient mechanisms to perform new internet applications such as the audio and video ones but also the new interactive ones such as DIS (Distributed Interactive Simulation).

Among the concepts studied in the project, the Application Level Active Network (ALAN) concept [Michael Fry, Atanu Ghost] seems particularly promising. An ALAN system consists of regular clients and servers located on the Internet or Intranet. Communication between servers and clients is enhanced by Dynamic Proxy Servers (DSP) that are located at optimal points in the network infrastructure.

We propose to deploy RLC and RMDP as bind or call time DPS code, we will integrate them in a more valuable way to the work of UTS. We will also address some of the questions about DPS approach versus router based approaches to distributed active network components. We will study if DPS could provide smart solutions to set the QoS policies within an Intranet or Internet using a Differentiated Services approach.

A major results of the Hipparch project is the definition of a Quality of Service framework. This framework called TOMTEN needs to be enhanced before it becomes a commercially viable product. The extension will allow to integrate some missing elements in TOMTEN and to follow its validation.

Finally, the Hipparch research leads to investigate new facilities. Provide flexible communication architecture is only possible if we are also able to provide efficient naming and addressing mechanisms. So, it is proposed to investigate the addressing problems in the context of a new network architecture providing transparent configurations to the end users.

The emerging information infrastructure consists of information services carried via heterogeneous networks such as the Internet. The heterogeneity is increasing as new technologies appear in the areas of high speed optical networks and mobile wireless networks. Real­time, multicast and mobile applications have communication requirements that are not well supported by existing ubiquitous communication protocols and architectures. A solution is to use application specific, tailor made protocols. The tailoring of communication systems for the efficient operation of heterogeneous "information appliances" is a highly skilled, time consuming activity.

In the HIPPARCH EC­AUS activity, We have shown the that:

• To make application tailored communication protocols and Integrated Layer Processing feasible, we need a protocol compiler to radically reduce the design to product cycle time and cost for new application protocols. The prototype compiler designed in HIPPARCH EC­AUS activity is only a control compiler that we used to validate ALF and tailoring.

• We also need an efficient protocol execution environment supporting the compiler generated protocols. The Application Layer Framing concept seems to significantly simplify these communication protocols.
• Network consciousness is needed to complement the ALF principle in order to make multimedia applications handle heterogeneous networks.
• architecture supporting heterogeneous networks and new applications should be based on both the concepts ALF and network consciousness.

The objective with the HIPPARCH LTR project is to investigate architectures based on HIPPARCH EC­AUS activity results (ALF, ILP, NCA, protocol tailoring), by designing new mechanisms and to build prototypes. In particular, we will show that:

• By making multimedia applications network conscious they can better handle the very heterogeneous information infrastructure and the varying network conditions caused by mobility and the multipoint nature of multimedia applications.
• By building network conscious applications using a specification language and a protocol compiler, we can radically reduce the time and cost for design and implementation of application tailored communication protocols.
• The ALF concept and the ILP implementation technique can substantially increase communication performance within a communication environment tailored to application requirements.

As explained in the following subsection, the goal of the project is to validate the previous architecture principle by implementing prototypes and widely disseminating them (standardization, software diffusion, transfer to industry).

The main research contribution of the HIPPARCH LTR project is to demonstrate the benefit of ALF/ILP based architectures for time constrained, multipoint, mobile communications and network conscious protocols and their applications. To achieve this, we will develop:

• A Protocol Compiler called ALFred, which will be a significant evolution of the one developed in HIPPARCH EC­AUS activity (adding new mechanisms, group communication, and support to Network consciousness). This protocol compiler will significantly reduce the design cost of multimedia applications. It will be publicly available to the scientific community for evaluation.
• Adaptive algorithms: Algorithms will be developed for the control of both convential and real­time multimedia applications in environments with a mix of mobility, real­time, multicast and low/high speed networks.
• Execution environment for real time protocols: mechanisms for finer grain of resource allocation and scheduling than is available today will be developed and provided in a protocol execution environment.

A prototype multi­media client/server application based on the World­Wide­Web will be designed and implemented to serve as a demonstration for the results described above. We intend to run this application over both high speed as well as mobile networks (GSM and packet radio LAN) in order to show the feasibility of network conscious protocols.

Our architecture (as well as the tools, algorithms, and execution environments designed in the project) will be compared to other communication systems architectures. Gains and feasibility will be analysed in depth.

In this section, we describe dependencies between HIPPARCH activities and the platforms used by partners. The objective of the HIPPARCH IT LTR project is to define new communication architectures and protocols based on these architecture principles. Such an architecture should be independent of the host platform, but must specify the services required from a platform and should specify the services offered to applications. With a platform we mean the operating system and hardware.

Real­time and network consciousness applications and protocols certainly require reserved resources from a platform. With resources we mean host systems resources, such as the CPU, as well as network resources such as available bandwidth. Abstractions of these resources, mechanisms and policies for sharing them according to a Quality of Service contract will be formulated as a part of an architecture. In the HIPPARCH LTR project, we will experiment with implementations of these architectures on various platforms. We will determine the performance offered to applications, the control given to users and how efficient the architectures are. To conclude, the architectures and protocols are independent of the platforms while a particular implementation is more or less dependent.

We believe that it is important that implementations and experiments are carried out on widely distributed and visible platforms so that our results can be further disseminated in industry and academia. However, various platforms offer very different functionality especially with respect to resource reservation. New operating system research have started to address this issue but they are not widely spread yet and stable for general usage.

That explains why, in accordance with our industrial partners, we have chosen the following platform characteristics:

• Network: The architecture designed is independent of the type of network used. As HIP¨ PARCH results will be proposed for standardization, the communication architecture designed will be developed for heterogeneous networks such as the Internet, and will not include any network­specific element.
• Protocols: Communications protocols used within the HIPPARCH architecture will be standardised protocols from the Internet environment. These protocols are: UDP and TCP at the Transport level, IP at the network level. We also intend to use RTP (Real­Time Protocol) and RSVP (reservation Protocol) that are two recent protocols introduced in the Internet to provide transmission facilities to real­time (voice and video) applications.
• Operating System: UNIX and Windows are the two most popular Operating Systems. Developing on Windows would be risky because it is "closed" and would not bring any added­value to the project results. Consequently, we have chosen Solaris for our developments on workstations and Linux for PCs. Porting between these two is easy. Porting to Windows could be made on industrial requests.

HIPPARCH partners have a broad experience in implementation techniques. There is no generic solution to high performance implementations. Host platform dependencies will have to be carefully analysed in order to maximise performance and efficiency. Most experiments can be carried out on the Unix platforms. Some experiments, in particular with host resource management reservations, will also be carried out on new operating systems, such as Exokernel from MIT and SPIN from University of Washington (this mostly concerns WP 3). They provide a higher degree of resource control than Linux and Solaris. This kind of experiments may also be demonstrated on Solaris and Linux but with less functionality. But the demonstration in WP 4 will be carried out on either Solaris or Linux.

Three major European companies, British Telecom (BT) in the UK, Ericsson Radio Systems AB (ERA) in Sweden and Dassault Electronique (DE) in France have expressed their interests in the project. They have also agreed to join the project's steering committee. In addition, Dassault­Electronique is a full working partner in the project. Both BT and Ericsson have already committed to directly fund UTS, in Sydney (Australia) in order to maintain a scientific collaboration between HIPPARCH and UTS. The industrial partners interests is summarised below.

Dassault Electronique DE is interested in on­board and real­time communication systems. DE considers that the following Hipparch methodologies and results as strategic:

1. the protocol compiler and its formal approach to the automated development of distributed applications.
2. the algorithms for network conscious applications.
3. the ILP technique, that will allow efficient usage of hardware resources.

The results of the HIPPARCH LTR project research is expected to have a direct and major influence on the networking technology developed by DE.

DE is developing a new generation Internet technology which will be at the basis of new communication equipments. This technology is commercialised under the name MUSICA. The results of the Hipparch research will be used to increase the functions and facilities of the MUSICA products.

British Telecom BT intends to extend the work of HIPPARCH by applying the notions of ALF and ILP in the context of public networks. In particular BT intends to explore how appropriate ALF/ILP profiles may be negotiated and synthesised within sessions between users (or user agents acting on behalf of users) and information service providers. BT endorses the WWW­focused experiment of the proposal as an appropriate research prototype and project outcome.

Ericsson Radio Systems AB ERA is interested in adaptive protocols that can adjust and compensate for the varying bandwidth and error rates of the radio media as well as the design and development of protocols and applications that are network conscious. ERA supports the ALF architectural idea for the design of protocols and believes that ALF protocols are useful for the wireless communication environment, since it gives simpler protocols, more efficient implementations, and makes it easier to design network conscious applications. A mobile unit must be efficient with respect to electrical power and size. The HIPPARCH approach could tailor protocols for the applications which in turn will reduce the number of CPU cycles for protocol processing. Such a reduction will save cycles for applications and make the unit more efficient. ERA plan to use the results in the ACTS project ON the MOVE.

To reach the objectives, and in order to work efficiently, we have divided the research issues into four work packages:

Each work­package is organised to focus on a dedicated problem with relations and dependencies to other work­packages clearly identified.

Each work­package has its own independent results that will be demonstrated separately.

Project results, standardization activities, and dissemination will be described shortly at the beginning of each work­package description (in the "WP Output" item), and specifically in task activities. Furthermore, each package has demonstration deliverables. All partners, including industrial partners, will participate in the evaluation of intermediate results and in the discussions on the directions to be taken in each work­package in order to get coherent research activities.

The UTS activities are complementing the tasks of the HIPPARCH partners. But still, the collaboration with UTS in the project is of major importance Their technical activities add value to the project, and their results may be integrated within the protocol compiler and the execution environment. UTS activities will be described in the "Take­up of results" section.

In work­package WP 4, contributions issued from the work­packages WP 1, WP 2 and WP 3 will be applied within a real­time multimedia application: an enhanced performance World

Wide Web client and server. WP 4 is the show­case of the project and provides the experimental platform.

Work-package 5 is proposed as an extension to the first work-packages. In WP 4 we demonstrated the accuracy of the Hipparch concepts. Nevertheless the promising results demonstrated in WP 4 need to be consolidated. So, WP 5 will allow to refine:

• the Active application architecture (proxylet concept) proposed to increase the flexibility and the efficiency of the network protocols and of the above applications,
• the Quality of Service framework and the associated mechanisms (traffic control, adaptive compression, monitoring…)

WP 5 will also allow the partners to study the consequences of naming and addressing using the Hipparch communication infrastructure.

Follows a summary of the resource involved for the first 4 work-packages (WP 1 to WP 4) and the requested funding:

INRIA, SICS and DE request from the EC the funding of 50 % of their costs.

UU and UCL request 100 % of the marginal costs cited above.

Follows a summary of the resource involved for the work-pakage WP 5 and the requested funding:

INRIA and DE request from the EC the funding of 50 % of their costs.

UU and UCL request 100 % of the marginal costs cited above.

WP Name: Automated generation and integration

WP Leader: INRIA

Participants: INRIA 30mm, SICS 6mm, UU 5mm

From: T0 To: T0+18

The Protocol Compiler designed in the HIPPARCH EC­AUS activity is a simple prototype that intended to validate a new architectural concept (ALF protocol tailoring and integration to the application) implemented in a formal framework. This prototype Protocol Compiler is a tool based on the ESTEREL language aiming to generate "ALF" code of the application control part [DCR95]. The compiler approach makes bindings at compile time. All possible options are encoded at the language level, including. This provides a very good vehicle for expressing ALF at the language level. The ESTEREL based Protocol Compiler that has been delivered at the end of HIPPARCH EC­AUS activity is in fact an "ALF compiler" i.e. it has no data processing capabilities.

This compiler will be enhanced in three steps:

• the HIPPARCH EC­AUS activity prototype compiler will be completed to be able to process data manipulation functions manually; this will lead to an early evaluation.
• The aspects related to automatic integration of data manipulation have not been studied in HIPPARCH EC­AUS activity, even if data description languages have been investigated. To provide a fully automated design environment, the ESTEREL compiler has to be completed with a data description compiler that we will call the "ILP compiler".
• Enhancement of the compiler with new capabilities in order to be able to address a larger range of multimedia application. Extension to multicast applications, to real­time, and to network conscious applications will be studied and, when relevant, implemented in the prototype of ALFred.

WP Output: The main result of WP 1 is an enhanced Protocol Compiler, called ALFred, supporting both ALF and ILP. It will be evaluated by DE for a possible product. There is no validation work carried out within the framework of HIPPARCH. HIPPARCH focus on communication aspects and the formal approach to protocol secure design is considered to be a side­effect of our integrated approach. It will have to be verified in another context.

The ALF compiler Task Number: 1.1 Task Leader: INRIA Participants: INRIA 18mm From: T0 To: T0+18 Input from: HIPPARCH EC­AUS activity, Tasks 1.2, 2.1 and 2.2 Output to: Task 3.2 and 3.3

Deliverable(s): INRIA­1 (report/public): Evaluation of the ALF Compiler, INRIA­2

(demonstration+report/confidential): ALFred, an Integrated Protocol Compiler Milestones: Final Version of INRIA­1 due at T0+6,

First draft of INRIA­2 due at T0+12,

Final Version of INRIA­2 due at T0+18.

First of all, the HIPPARCH EC­AUS activity compiler will be completed with the following enhancements:

• Optimisation of the code generation using tree reorganisation techniques. In its current state, the prototype Protocol Compilers designed in HIPPARCH EC­AUS activity makes various type of optimisations that are carried out by the ESTEREL compiler. We will associate to the protocol compiler an optimiser that performs "static" analysis of the specification in order to determine the most frequently used path. The code generator uses statistical information to optimise the executable code following the importance of each path. We will also investigate mechanisms for dynamic evaluation of the most frequently used path. Techniques used to realise dynamic optimisation are based on tracing the executable code.

• Definition of the interface between the ALF Compiler and the data manipulation compiler (that will become in task 1.2 the ILP compiler). The data manipulation compiler can take advantage of informations that could be provided by the ALF compiler e.g. a module that will describe its choice to the data manipulation compiler. This module will contain, in the data description language, the list of the data description function used by the application control, the PDU (Protocol Data Units) headers added to the application ADUs, and the control PDU managed by the communication mechanisms.

Description and interaction between application data flows. While designing the HIPPARCH EC­AUS activity Protocol Compiler, we have discovered that the definition of ADU flow depends on the media type and on the ordering constraints between the ADUs. In order to support an extended set of applications, we must address the interaction of several flows belonging to the same application. This will have an impact on the way application modules will be designed and integrated.

This will allow us to make a quantitative and a qualitative evaluation of the prototype compiler that will be described in Deliverable INRIA­1. We will use INRIA­1 as the baseline for the enhancement of HIPARCH EC­AUS activity compiler. For this purpose, we will use applications automatically generated with the compiler. This performance analysis will teach us how convenient and useful the protocol compiler is; it will also be the opportunity to analyse in details the consequences of out of order processing on the performance of ALF architectures.

Then, INRIA will enhance the prototype Protocol Compiler designed during the HIPPARCH EC­AUS activity (which will be called the ALF compiler, or ALFred in the HIPPARCH LTR project) with the following features (or eventually design a new one following results obtained in INRIA­1):

• Extend the range of applications that can be processed by the protocol compiler. Including real­time applications. In HIPPARCH EC­AUS activity, the prototype of the Protocol Compiler has been designed to satisfy the requirements of simple applications; mechanisms that are provided are retransmission on timeout, flow control by sliding window, out­of­sequence data delivery. New mechanisms for real­time transmission control, flow control, and congestion control will be supported.

• We will study the integrate mechanisms for network consciousness. Such mechanisms will be designed in task 2.1. Once the mechanisms are designed, they will have to be provided to the application. Some of them will be provided in a transparent way (the application will not know it); some other in a non transparent way (the application will be asked to decide how to adapt). The problem of non transparent adaptation will be addresses in task 2.3. The adaptation characteristics will be translated in term of parameters that will be provided to the application designer to specify the type of adaptation required. We will then try to automate the integration of those of the mechanisms designed in task 2.1 that can be integrated automatically.

• We will integrate the ILP compiler in ALFred after completion of task 1.2.

The final objective of these enhancements is to provide a tool with maximum integration and automation that will be disseminated for free in the scientific and the industrial community.

When the comparison will be possible, the ALFred compiler will be compared to the HIPPARCH EC­AUS prototype (evaluated in INRIA­1) within the INRIA­2 deliverable.

Task Number: 1.2

Task Leader: INRIA

Participants: INRIA 12mm, SICS 6mm, UU 5mm

From: T0 To: T0+12

Input from: HIPPARCH EC­AUS activity

Output to: Tasks 1.1, 3.3

Deliverable(s): INRIA­3 (report/public): Prototype ILP compiler,

SICS­2 (report/public): Performance effects of CPU register usage for integrated data

manipulation functions. Milestones: Final Version of INRIA­3 due at T0+12, First Draft of SICS­2 due at T0+6, Final Version of SICS­2 due at T0+12 Description: It is now accepted that ILP techniques need to be used to achieve efficient protocol implementations in modern computer systems. However, how ILP techniques can be used in the above model, where the protocol is synthesised from a collection of protocol functions, is not clear. The problems associated with ordering constraints between different data manipulation functions, different sizes and structure of the processing unit that must be manipulated by these functions, make the integration process complex. In the HIPPARCH EC­AUS activity, we studied hand­coded solutions based on various data description languages, but no work was done on the automation of the data manipulation steps. However, the interest of the Protocol Compiler is very limited if all data manipulations have to be hand­coded.

This task is dedicated to the design of the ILP compiler. This compiler will be run at the same time as the ALF compiler to integrate data manipulation functions within the ILP loop. The ILP compiler needs both input from the application designer (the ADU format, and the specific functions and procedures) and from the ALF compiler (protocol mechanisms introduced, PDU header and type definition).

INRIA will design the ILP compiler starting from an existing stub compiler (ISC, the INRIA Stub Compiler). This compiler will integrate data manipulation functions together in an ILP loop, and provide results of the execution to the ALF compiler. The first prototype of the ILP compiler will not receive input from the ALF compiler. The second prototype will be integrated to the ALF compiler in order to maximise the automation of the implementation design process (and the design of the ALFred compiler). INRIA will use an annotated C language to describe the data part of the application.

The information used by the ILP compiler is provided partly by the application designer (description of the ADUs format), and partly by the ALF compiler (list of data manipulation functions to be integrated to the application and protocol header format). The ILP compiler depends on the implementation environment as it defines the interfaces between host environment (and Operating System) and the ESTEREL control automaton. The ILP compiler is tailored to a particular execution environment with the aim of achieving high performance.

An integrated implementation of a set of data manipulation functions needs more processor registers than the corresponding serial implementation. SICS will analyse the register usage of manipulation functions in both integrated and serial implementations, and experimentally measure the performance effects when the integrated implementation needs more registers than available. The results will influence the use of the ILP compiler in the design of ALFred.

WP Name: Network conscious applications

WP Leader: INRIA

Participants: INRIA 18mm, SICS 5mm, UU 3mm, DE 4mm

From: T0 To: T0+12

The ALF approach allows to integrate application specific controls within multi­media applications. We anticipate that these applications will have to adapt to very variable networking environments, such as very high speed ATM links, conventional digital connections, and wireless networks. For example, a wireless connection typically means relative low and varying bandwidth, high error rate and frequent loss of connectivity. A mobile unit on a wireless connection may trade protocol processing, message and header size against bandwidth while a unit on a high speed optical fiber may have the opposite trade­off. We propose to develop and evaluate algorithms for such "network conscious" applications that adapt automatically to these environments.

Network conscious applications may adapt the information density to the available bandwidth and quality of service. They will either send only the most significant data when the bandwidth is scarce, or provide the users with a full service when the bandwidth is plentiful. Different applications require different algorithms: the "most important" signals are not extracted in the same manner from an audio stream as from a text document; this extraction (that could be seen to be a prioritisation of application sub­flows) also depends of other reliability mechanisms like redundancy.

We believe that ALF is useful for information adaptation. Intermediate nodes could understand the information content or context of an ALF message and reduce the content appropriately when a low bandwidth link will be used.

Application adaptivity can be performed either entirely within the application itself or can be done entirely by the system. If it is done within the application, there will be no mechanisms for coping with incompatible resource demands, and policing the usage of resources. In order for the system to perform adaptation it will need to have extensive knowledge about every conceivable application's requirements. Thus a hybrid approach where the system provides the management and policing the use of resources will be adopted. The system will also need to provide a facility to notify the applications of changes in availability of resources. Individual applications will therefore be free to build in adaptations that suit them best.

WP Output: QoS models and algorithms for network consciousness. These results will be proposed to standardization groups: QoS models to IETF RSVP, flexible protocol algorithms to UMTS and network awareness results to the IETF TCPng group.

Algorithms for Network Consciousness Task Number: 2.1 Task Leader: INRIA

Participants: INRIA 12mm, SICS 5mm, UU 3mm, DE 4mm

From: T0 To: T0+12

Input from: Task 2.2

Output to: Tasks 1.1 and 3.1

Deliverable(s): INRIA­4 (report/public): Algorithms and protocols for network conscious applications,

UU­1 (report/public): Trade-offs between computing resources and communication

resourcesMilestones: Final Version of INRIA­4 due at T0+12, First Draft of UU­1 due at T0+6, Final Version of UU­1 due at T0+12

New networks will diverge from current networks in two ways. Many backbone networks will be made up of high speed fibre optic links all the way to the desktop. In many cases, though, the last hop in the network will be a wireless link to a portable end­system. It is advantageous to use the same network protocol throughout such an internet of heterogeneous links. Within this task, we will build algorithms that will be used by applications to adapt on top of a heterogeneous internet.

• INRIA will focus on real­time and multicast applications where adaptation is a more complex because of time constraints.
• SICS will focus on the adaptation to wireless links. On such links, applications should be able to adjust the amount of control information in packet headers versus data depending on the speed of the link, trading off network robustness for efficient use of bandwidth.
• UU will focus on how computing resources can be traded off against communication resources in order to achieve optimum performance within constraints put on the communication, e.g., by limited link throughput, computing power or time constraints. Experiments and measurements will be performed on hosts and routers attached both to a packet radio local area network and a high speed network.

Not only mechanisms for dynamic adaptation will be designed, but we will also study the way an application will be asked to provide information to the protocol compiler in order to know what type of adaptation is possible. This task will have an influence on task 2.2, where we study the impact of this adaptation on the Quality of Service (QoS). Even if network consciousness support is systematically provided by the ALF compiler (in the same way as flow control for example), information on how the adaptation is possible and what type of adaptation will be efficient will have to be provided by the application.

Impact of Network Consciousness on QoS Task Number: 2.2 Task Leader: INRIA Participants: INRIA 6mm From: T0 To:T0+6 Input from: HIPPARCH EC­AUS activity

Output to: Tasks 1.1, 2.1 and 4.1

Deliverable(s): INRIA­5 (report/public): QoS model for network conscious applications

Milestones: Final Version of INRIA­5 due at T0+6

Description: The consequences of network consciousness as a design principle is a complete modification of the communication architecture. This approach is completely orthogonal to classic layered architecture and to associated complex QoS management models. In fact, a QoS engine needs to be very simple; it has to help an application designer to obtain the best possible transmission in the used environment. We propose to study here the consequence of network consciousness on the way an application designer will specify its application. A simple QoS model dedicated to network conscious applications will be designed, and tested.

While designing the first prototype of the Protocol Compiler, we had to deal with very important problems related to the application specification. While there is information that appears naturally in the application formal specifications (synchronisation, parallelism, control automaton), some other cannot be "invented" or "guessed" by the Protocol Compiler. They have to be provided by the application designer; and eventually by the application user. During HIPPARCH EC­AUS activity we identified some of this information, that has to come from the application designer:

• delivering order of sequence
• type of traffic (time constrained or not)
• level of reliability

It makes only the basis of a new QoS model, and more work needs to be done to make a more exhaustive analysis of the application requirements (for real­time and multipoint in particular); and to understand the consequence/side­effects of application adaptivity on the QoS model.

The prototype Protocol Compiler will be of great help to analyse various QoS parameters and models for multimedia applications that would have been specified in ESTEREL.

This task is also the place to unify our description of applications requirements both in terms of communication and resource.

WP Name: Protocol support environment and resource management

WP Leader: Uppsala University

Participants: UU 24mm, INRIA 18mm, SICS 9mm.

From: T0 To: T0+24

Description:The protocol implementations generated by the ALF and ILP compilers from work package 1 will need services common to all protocol processing, such as a buffer management system, an event handler and interfaces to host operating system and communication hardware. The compiler will generate protocol code that requests resources from the operating system. The resources include the CPUs for protocol processing, bandwidth for transmission and memory, from fast cache to slow secondary memory, for packet buffering and processing. We will investigate operating system services and execution environments that can allocate these resources according to negotiated end­to­end QoS contracts.

In this project we will expand this environment with real time resource management for supporting time­constrained applications, such as audio and video. In the EC­AUS activity we focused on performance without any consideration about concurrent and competing communication streams. The aim was to reduce the number of used CPU cycles in order to increase the performance. In this project we want to provide mechanisms for scheduling communication resources in order to provide predictable delay, application­to­application. The aim is to eventually integrate the environment with the protocol compiler in WP 1 and to use it in the WWW­demonstration described in WP 4.

Traditional real­time applications require a certain QoS from the system. Network conscious applications behave differently. They continuously sense the communication quality and try to adapt to the changes. This difference in application behavior is also reflected in the protocol support environment and resource management.

WP Output: Environment for real time resource management, supporting time constrained and network conscious applications and mechanisms for real time scheduling of communication processing resources in end systems.

Application­to­application resource scheduling and management Task Number: 3.1

Task Leader: UU

Participants: UU 22 mm, INRIA 12 mm, SICS 3 mm

From: T0 To T0+24

Input from: HIPPARCH Phase 1, Task 2.1

Output to: Tasks 3.2, 3.3 and 4.2

Deliverable(s): UU­2 (report/public): Report on experiments with a host resource management

architecture, INRIA­6 (report/public) Report on experiments with IntServ, the Internet solution for

Traffic control. Milestones: First Draft of UU­2 due at T0+6, Second Draft of UU­2 due at T0+12, Final Version of UU­2 due at T0+24, First Draft of INRIA­6 due at T0+12

Final version of INRIA­6 due at T0+24

To be able to deliver a predictable real­time service, critical resources in the end system need to be carefully controlled. It is not obvious what the key resources are, how they are influenced by network conscious applications or how they will influence the QoS model being developed in task 2.2. Therefore the approach in this task will be to first to identify the key resources and thereafter methods for resource requirement specifications. Such a key resource is the CPU caches which a programmer normally can not control. Unpredictable conflicts in caches has a profound impact on performance. We will study this impact.

Two methods of specifying resource requirements are reported in the literature, namely through an extended API [Nob95] and through an extension to a language [Flo93]. Both will be examined to determine the most appropriate method and the compatibility/relationship to findings in task 1.1.

We plan to experiment with new abstractions and implementations to control real­time host resources for multimedia communication applications. Our concern is the efficiency and ease of these mechanisms. We want to provide to the application programmer abstractions and mechanisms to low­level resources in the kernel without compromising security. Actors in the University of Lancaster terminology and spindles in the University of Washington terminology are abstractions that can operate in the user as well as in the kernel space. Similar abstractions can be found in Exokernel from MIT and Scout from University of Arizona. Thereafter we will develop mechanisms and algorithms to schedule and manage these resources.

We propose an integrated, holistic approach to scheduling of these communication and computational resources, i.e. the integration of network and operating system scheduling. A one­to­one mapping of "network flows" to end system threads will be studied. The research will build on previous research done separately on real time threads and research on network resource reservations such as RSVP and flow management. Initially, the resources to be managed will be limited to memory, bandwidth and CPU. We propose to schedule according to communication events, such as deadline scheduling according message time­stamps and co­scheduling of host system resources to network traffic classes.

We will evaluate IntServ, which is proposed by the Internet community to control, in association with the RSVP protocol, bandwidth allocation on networks. Of interest is the control of resources over heterogeneous networks. It does not replace application network adaptation, but is a necessary complement.

An experimental API supporting protocol modules built with ALFred Task Number: 3.2

Task Leader: SICS

Participants: SICS 6 mm

From: T0+6 To: T0+18

Input from: Task 1.1, Task 3.1

Output to: Task 3.3

Deliverable(s): SICS­1 (software+report/confidential): Experimental API software

Milestones: Final Version of SICS­1 due at T0+18

In the EC­AUS HIPPARCH activity we developed a no­copy communication API and an experimental implementation [AGM95, ABM95]. The experiments concerned data transfer and buffer management, and the main purpose was to increase performance.

In this task we will extend the API to include support for some of the concepts and results developed in Tasks 2.2 and 3.1 regarding QoS specification, real­time scheduling and resource management. The approach will be to investigate which resources need to be handled at the API and how requirements for resources are specified at the API. We will use the results from work package 2 concerning the needs of network conscious applications, but also study previous work on QoS specification, for example the proposed Internet flow specification [RFC1363].

The purpose with the API is to be the lower layer communication interface used by the protocol module produced by the ALFred protocol compiler from work package 1. We will therefore also investigate what additional API support the protocol modules need.

Integration with ALFred Task Number: 3.3 Task Leader: INRIA Participants: INRIA 6mm, UU 2 mm From: T0+12 To: T0+24 Input from: Tasks 1.1, 1.2, 3.1 and 3.2

Output to: Task 4.3

Deliverable(s): INRIA­7 (Demonstration + software+ report/ confidential): Integration of ALFred in the HIPPARCH execution environment.

Milestones: Final Version of INRIA­7 due at T0+24

Description:As explained in task 1.2, the executable code produced by the ALFred Protocol Compiler (including both the ALF and the ILP compilers), has to be integrated with a protocol support environment. This protocol support environment will provide the facilities to manage the system resources. The protocol generated by the compilers will need to execute OS primitives in order to manage resource allocation, cache, registers, timer, and process scheduling.

In this task we will work on the integration of the code produced by ALFred and the experimental results from Tasks 3.1 and 3.2. The purpose of the task is to gain experience from the integration which will be used to enhance both the compiler and the protocol support environment.

Name: Demonstration based on the World Wide Web

WP Leader: DE

Participants: UCL 34 mm, UU 2mm, SICS 4mm, INRIA 6mm, DE 12mm

From: T0 To: T0+24

Description:A demonstration of a WWW client and server which utilise ALF and ILP concepts to enhance performance, as well as deploying the lessons learned from the network conscious application experiments. We will try to demonstrate the network ''consciousness'' by running the WWW client over a GSM link and a packet radio LAN. There is a great deal of activity in the area of WWW, in the IETF and the W3C, in both of which organisations this project is well represented, as well as with the commercial Web browser and server vendors such as the Netscape corporation and Microsoft. However, most of the current effort is in HTML, and on server performance enhancements. Little work to date has been undertaken in fundamentally repairing the damage done by the mis­design of HTTP.

Furthermore, this work is different from the minor changes to HTTP involved in both HTTP 1.1 and HTTP 2 work, in that we are addressing the entire protocol stack, and both at the server and at the client.

The work on Real Audio, which is essentially "audio­on­demand", whilst relevant, is relatively primitive compared with the work in this WP, since we will enable realtime retrieval of potentially interactive audio and video from high performance servers, and retrieval to groups of receivers.

The work from Sun Microsystems on the new program language, Java, enables some interesting new approaches to distributing computation through the World Wide Web (via active pages, and Applets and so forth). However this is an entirely different area than our work, which is on the optimisation of delivery of any kind of data, whether it be video, audio, or Java byte code executables, to clients, over fast, slow, lossy and non­lossy nets, to single receivers and groups of receivers, both for elastic traffic, and realtime.

WP Output: The demonstration will be comprised of two parts firstly the WWW client and server will be designed and hand built, the output from this process will be used to produce a specification which can be used to automatically generate a WWW client and server. The performance of these two sets of applications will then be compared.

This work­package results will directly influence future standards evolution for WWW through INRIA's activities as the European leg of the WWW Consortium.

Deliverable, UCL­2, on next generation HTTP will be contributed to AVT and TCPng IETF working groups. UCL­1, on Application specification, will be delivered to W3C.

Application Set Specification Task Number: 4.1 Task Leader: UCL Participants: UCL 13 mm, DE 2 mm From: T0 To: T0+18 Input from: HIPPARCH EC­AUS activity and Task 2.1 and 2.2

Output to: Tasks 4.2 and 4.3

Deliverable(s): UCL­1 (report/public): Application Specification

Milestones: First Draft of UCL­1 due at T0+6,

Final Version of UCL­1 due at T0+18

Produce a specification of the WWW client and server, this should encompass:

1. Synchronisation of multiple streams from multiple sources for network conscious applications. There are a variety of synchronisation that have been explored in the research community ranging from complex NTP like protocols, through to simple alignment of adaptive playout buffers based on RTP Source Media timestamps. The latter approach is appropriate in this context.
2. Adaptive selection of protocols to suit underlying capacity e.g. for wireless versus wire communication. We envisage here a very heterogeneous networking (various technologies based on wired and wireless communication supports) and application environment.
3. Multicast packet delivery. Multicast allows much more efficient network utilisation. We can envisage preloading WWW caches, or playing back media to multiple simultaneous viewers (e.g. remote classroom support) all requiring multipoint delivery of data from a WWW server to a set of clients.

The specification for the WWW client/server interaction will cover the details of dynamic/adaptive replacement of the current stack, HTTP+TCP+IP, with a new stack that is chosen/configured for each application, and for each network scenario, where the input for these will come from other work packages as appropriate. For example, when retrieving video from a Web server, to multiple, concurrent clients, it is appropriate to use:

• multicast

• RTP

The integration of the media retrieval with the congestion signal from the network through extensions to previous HIPPARCH work on network conscious applications will greatly extend the applicability of RTP. We will investigate the possibilities for interfaces to explicit traffic scheduling such as RSVP and CBQ (Class Based Queuing), as well as implicit rate­adaptive schemes such as VCJJ.

We will feed the results to the WWW standards work on HTTPng (the ''next generation'' of the Hyper­Text Transfer Protocol) used for WWW client/server accesses, and on RTP reliable (which is the extension of RTP with end­to­end control for reliable multicast).

The approach that we will use will entail the analysis of existing high performance transport protocols (much of which information is available from HIPPARCH EC­AUS activity), and their applicability to the full range of data types to be retrieved from the Web. We will then construct a family of micro­protocols, each of which address a particular data type. We will then synthesise the full protocol, based on the ALF and ILP principles, using the RTP/UDP/IP basic transmission framework, but producing a set of profiles for the new HTTP protocol system matching the micro­protocols specified.

Hand Crafted HTTPng communication subsystems Task Number: 4.2

Task Leader: UCL

Participants: UCL 15 mm, DE 2 mm

From: T0+6 To: T0+18

Input from: Tasks 3.1, 4.1 (and indirectly tasks 2.1, 2.3)

Output to: Task 4.3

Deliverable(s): UCL­2 (software + report/confidential): HTTPng protocol specification

Milestones: First Draft of UCL­2 (report) due at T0+12,

Final Version of UCL­2 (report + software) due at T0+24

Hand build a WWW client and server application using ALF and ILP concepts as well as incorporating the network "consciousness". Instrument the applications in order to compare performance. Drawing directly from the scenarios in Task 4.1 and other WPs, we will hand build the protocol stacks for the multicast, mobile, and parallel end system cases, and devise standard interfaces and techniques for merging the code required for the modules when separate. This work will be fed back through the compiler work. Code size, performance and implementation time will be carefully monitored. UCL and SICS/UU will collaborate closely on the use of system simulations, implementation and integration of the components for this work­package. Existing collaboration in exactly this way in past work has proved successful. The report will be fed to the W3C as well as going to the IETF to further work on TCPng and Transaction TCP.

The protocol implemented will be made available to the community through normal IETF and W3C paths. Being built on RTP/UDP/IP, it is readily portable to many underlying transmission networks, and will be trivially portable between the common operating system platforms in use, Unix and Windows.

There will inevitably be some interaction with the structure of the client and server architecture, since current implementations are based on the classic RPC model of Web Page retrieval, which is synchronous, and uninterrupted, whilst our model will be asynchronous and incremental for some data types. The changes to the application will be fully documented as part of the implementation support work.

Task Number: 4.3

Task Leader: DE

Participants: UCL 6mm, UU 2mm, INRIA 6mm, SICS 4mm, DE 8 mm

HIPPARCH (21.926) Project Programme 49

From: T0+18 To: T0+24

Input from: Tasks 3.3, 4.1, and 4.2

Output to: WP 5

Deliverable(s): DE­1 (report+demonstration/confidential): Comparison of the WWW applications.

Milestones: Final Version of DE­1 due at T0+24

Description: We will illustrate our approach by proposing a core experiment, based on the World Wide Web, that will provide a show­case for all of the project results.

Using the specification from Task 4.1 and lessons learned from the other work packages create formal specifications which can be used as input to the compilers generated by WP 1.

A key difficulty in carrying out the integration is often that of measuring success. However, in this case, we have two simple benchmarks. We will not only have carried out the exact same task by hand in Task 4.2, resulting in a baseline system against which to measure the performance of the automatically generated systems, we will also be able to compare the relative ease of the automated procedure with the manual one. The characteristics of the demonstrated systems highlighted by the demonstration will be:

• out of order processing of packets (speeding up the display),
• selective retransmission, for a more efficient error control,
• real­time rendition of audio and video documents, to groups of receivers
• servers to control the resources allocated to various users, implementing explicit classifications and (max­min) fairness control policies.

Specific detailed experiments to characterise the browser and server load, the overall throughput (or goodput), the transaction latency, and jitter will be devised. These will ascertain to what extent the new HTTP, both manually and automatically implemented, has improved over the existing HTTP (1.1).

We will, in the process, demonstrate ''network­consciousness'' by running the WWW client over a variety of networks, such as GSM links, packet radio networks, standard LANs and ATM channels. The HTTPng devised in 4.1 and 4.2 will be shown to adapt (and reconfigure) appropriately, as the underlying transmission provides more or less capacity, lower or higher latency, and varying loss rates. The goal is to maximise network power, whilst minimising cost to the user.

This work will be carried out with careful collaboration between INRIA, UCL, and DE. The results of both Task 4.2 and 4.3 will be made available to HIPPARCH industrial partners first, since they will provide a flexible approach to providing multimedia through WWW over a wide range of network infrastructure, including many that are not part of the current Internet or ATM pilots, hence giving a strong research advantage.

The demonstration will involve the industrial partners through existing local high speed network platforms. UTS will be an important experimentation site as they will introduce significant transmission delays and lost in the transmission due to their remote location.

The demonstration will be comprised of two parts firstly the WWW client and server will be designed and hand built, the output from this process will be used to produce a specification which can be used to automatically generate a WWW client and server. The performance of these two sets of applications will then be compared.

A set of scenarios will be developed to enable effective comparison, based around a set of ideal users. For example, for incremental, realtime audio and video, we envisage a distance learning situation. For bulk data over lossy wireless networks (to stress automatic out­of­order exploitation), we might devise a situation such as a tourist downloading a map from the web to a hand held system. For conventional sequences of short transactions, a scenario such as an online tutorial, or researcher searching for a set of documents might serve. The scenarios will be documented, and a set of expected performance goals set out, so that we have a valid base for comparison between the output of WP 4.2 and 4.3.

This demonstration represents a very ambitious attempt to synthesise all the output from the project, since there is a full range of data types, and underlying network conditions represented in the demonstration scenario, and this will stress the automatic generation work from the rest of the project fully. However, have carried out a number of these types of experiments on other projects, and the procedures for the comparisons we will make here are well established.

Name: Results consolidation

WP Leader: DE

Participants: UCL 9mm, UU 11mm, INRIA 9.5 mm, DE 15 mm

From: T0+29 To: T0+35

Description:WP5 is proposed as an extension of the previous works. The motivation is to carry more in depth the integration of the developments provided as part of phase 1 (WP1 to WP4), including new topics which have been estimated of prime interest.

The first topic included in this extension is related to the dynamic deployment of new applications or protocols. The " Proxilets server" approach proposed by UTS is applied to other HIPPARCH developments. (RLC/RMDP in WP 5.1, and MUSICA-VIP in WP 5.4)

The second subject addressed as part of this new phase is the problem of dynamic management of the QoS. TOMTEN framework will be completed to enhance the previous capabilities. Higher interactivity will be provided at the OS level in order to reach a better use of resources in accordance with application and network constraints.

The third task (WP5.3) deals with a new topic. "Naming and Addressing" is a need that has been identified of major concern regarding the automatic deployment of new services through the net. Classical addressing schemata based on location of resources have to be extended.

The last task is providing the consolidation of the new developments. Tests and evaluation results conducted during extension will be proposed.

WP Output:

• Application Level Active Network (ALAN) system description and assessment.
• TOMTEN QoS framework description and assessment.
• Proposals to enhanced the Naming and addressing mechanisms.

These results will be used by the partners to influence standardisation works in the IETF working groups.

Proxylet Architecture Task Number: 5.1Task Leader: UCL Participants: UCL 6mm, DE 1mm. From: T0+29 To: T0+35 Input from: WP4

Output to: Tasks 5.4

Deliverable(s): UCL­3 - DPS RLC Implementation (code)

UCL-4 - Document Describing Proxylet Architecture

Milestones: Final Version of UCL­3 and UCL-4 due at T0+35

In Work Package 4, UCL put together novel protocols in the context of the World Wide Web architecture, initially simply as a useful and visible platform for demonstration of novel protocol architectures.

Another goal of this work in the HIPPARCH project was to derive a new version of the Hyper-Text Transfer Protocol, HTTP. In practice, what emerged was a framework, now commonly used but not explicitly described formally anywhere, for adding protocols between clients and servers in the World Wide Web, by using the indirection facilities in the initially deployed clients and servers, namely proxy services. Client and Server side proxies and HTTP redirection allow the incremental deployment of new protocols without the need for new versions of the web server and client software. Thus the RMDP and RLC protocols developed at UCL manually, and automatically derived from specifications by INRIA, were deployed in proxy servers.

In parallel with this, work at UTS was formally deriving a novel distributed computing paradigm named Application Level Active Networking. This involves the use of Dynamic Proxylet Servers, which allow bind time or call time loading of new service code into the proxy systems. UTS have demonstrated this work by deploying audio transcoding and streaming services in the DPS systems, and thus enabling existing clients and servers to provide streamed audio.

For this work package, we will apply the same technology to the deployment of RLC and RMDP. In the work to date in WP4, these were manually deployed in conventional proxies which were "hard coded", i.e. the protocols were made available at system compile time. By deploying RLC and RMDP as bind or call time DPS code, we will integrate them in a more valuable way to the work of UTS. We can also validate the UTS and UCL and INRIA work in a fully integrated fashion.

The system will consist of a DPS version of RLC, which will form deliverable UCL-3 (code, delivered to DE), and a formal description of the overall architecture which will form deliverable UCL-4 (paper study, delivered to the project and the fundign agencies and industrial partners, including BT). In describing the DPS and RLC integration, we will also address some of the questions about DPS approach versus router based approaches to distributed active network components. A paper comparison of RLC in DPS with PGM will be made. A critical area for research will be the choice of location of DPS systems to load RLC modules into a distributed fashion. This is the core of the novel work in this WP. We will base our approach to this on an algorithm based on that used by I. Kouvelas in his PhD work on Self Organising Transcoders (reported in the NOSSDAV 1998 paper, available at ftp://cs.ucl.ac.uk/darpa/sot.ps.gz).

TOMTEN QoS Framework Task Number: 5.2Task Leader: UU Participants: UU 8.5mm, DE 1mm. From: T0+29 To: T0+35 Input from: WP4

Output to: Tasks 5.4

Deliverable(s): UU­3 - Adaptive compression in the TOMTEN framework

UU-4 - Experiences of reactive feed-back scheduling

Milestones: Final Version of UU­3 and UU-4 due at T0+35

In the HIPPARCH project a feed-back scheduler has been designed and implemented in a Linux environment. In this task we will simplify the scheduler and move it to FreeBSD and merge it with the Lazy Receiver Processing mechanism for appropriate network interrupt handling. An utilisation monitor will be integrated with the scheduler and a user interface will be added. There is no need for the user to a priori specify or otherwise allocate the resources of the client machine. The feed-back approach will do the allocation dynamically to the need of the application and current QoS. The user will only need adjust the proportion of resources when there is an overload situation. The user interface builds on the principle that the user attention is a scarce resource in a similar way as the "unhappy" button of the TOMTEN framework and the system is hence reactive to the user. In this task we will demonstrate the effectiveness with the

approach both in less than full load as well as in an overload situations.

In this task we will also integrate the adaptive compression algorithm developed in task 2.1 and the monitoring tool from task 3.2. The adaptive algorithm is implemented in the Linux kernel and it will be moved to the user space of the TOMTEN proxy and client. Information about queue length and other parameters, such as CPU cycles, bandwidth and latency for the adaptation is obtained by the monitoring and probing tool. This information is used by the proxy to react on different situations.

The reactive and feed-back scheduler results will be disseminated as reports and demonstrations at academic conferences. The purpose of this extension is to produce a high quality paper for a wider spread of the results.

Naming and addressing Task Number: 5.3Task Leader: INRIA Participants: INRIA 9mm, DE 3mm From: T0+29 To: T0+35 Input from: WP4

Output to: Tasks 5.4

Deliverable(s): INRIA­8 - Naming and addressing in the Internet

Milestones: Final Version of INRIA-8 due at T0+35

ALF has been proved to be very efficient in the case of Distributed Interactive Applications (DIAs) on the internet. The new generation of protocols based on ALF place the control of data transmission, i.e. managing errors and congestion, at the application level. Applications such as Web and MiMaze advocate for more integration between the end-to-end transmission control and the application. But more and more DIAs are being designed (such as games, DIS, interactive home applications), and a hierarchical naming environment is required for these applications.

In our work, we will analyse first the consequences of ALF on data naming. Then, we will design a new hierarchical naming approach based on recent work by [Raman97] and [Fuchs98]. The new approach should solve the problem of mapping between application data and multicast distribution groups.

In our work, we will have to deal with issues relative to both object management, multicast address mapping and object filtering.

Integration and Experimentation Task Number: 5.4Task Leader: DE Participants: DE 9mm, UCL 3mm, UU 2mmFrom: T0+29 To: T0+35 Input from: WP4 and tasks 5.1, 5.2, 5.3

Output to:

Deliverable(s): DE-2 - Final demonstration

DE-3 - Final project report

Milestones: Final Version of DE-3 due at T0+35

Final demonstration due at T0+35

As part of the WP, Dassault Electronique intends to conduct two main activities. At once, Dassault Electronique will be responsible for the testing and the evaluation of the new developments (Specifications and/or new software delivered by the partners), but D.E. also intends to study internal policies that could be used to support the dynamic deployment of new applications or protocols within the boundaries of an organisation such as an industrial or commercial company. Investigations will be based on DSP concepts and mechanisms. Even if we will mainly focus our mind on intranet cases, we could also investigate more in depth the problem of the use of public infrastructure to interconnect Intranet clouds (Extranet), having in mind the security constraints.

Today configuration of firewall filters is done and shall be maintained manually. The process is not efficient and unsuitable for the dynamic deployment of new applications. For that reason, we could investigate the possibility to enable the automatic delivery of new applications by approved providers.

For the purpose of the second activity, D.E. will define and implement transparent "Plug and Play" capabilities that will allow mobile code to travel from clients to servers and from server to clients, every participants being located on an intranet. D.E. should investigate the problem of dynamic distribution/release of software (applications and/or protocols such as MUSICA-VIP) when pieces of code are loaded only on request.

D.E is also interested by the interactive management of the QoS policy at the intranet level. Studies conducted as part of the TOMTEN Framework will be used, refined and completed in order to allow management and enforcement of CoS/QoS constraints from a global point of view. Strategies for remote loading of CoS and QoS orders should be under scope.

Deliverables (Final Versions) will be circulated to the Steering Committee before being delivered to EC. Draft deliverables will be circulated within the project members and to the Commission. A table that describe deliverables due date in accordance to the related task is provided hereafter. The title of each deliverable and its type can be found in the Workplan section.

The status of Deliverables is Public when it is a report, and Confidential when it is a software or a demonstration. But demonstrations will be advertised and open to interested people.

FD: First Draft, SD: Second Draft, FV: Final Version.

The human resources in man months (mm) allocated to the first 4 work-packages of this project and broken down by institution are shown in the table below.

The human resources in man months (mm) allocated to the work-package WP 5 of this project and broken down by institution are shown in the table below.

The management of the HIPPARCH LTR project will be based on the same structures as HIPPARCH EC­AUS activity.

• A mailing list of all project participants is already existing. It will be extended to the industrial partners.
• Video conferences between project partners will be used regularly. The industrial partners will have the video­conferencing tools installed in order to be able to attend the regular "virtual meetings".
• Regular mail and fax will also be managed.
• Two regular meetings every year. The meeting at the end of each year is the general workshop and HIPPARCH review meeting of all participants.
• Exchange of researchers and longer visits between partners

The central coordinating and decision body of the project is the Project Coordination Committee (PCC). The PCC contains a scientific manager and one member from each project partner.

He will assist in the annual review and then hand over to his successor.

The Steering Committee (SC) will be following the project development and will control that the project research is going in the expected direction. It will give advice on scientific and technical evolution of the project with respect to the results expected by the industrial partners.

The SC consists of the PCC members, to which are added representatives from the other entities participating to the project, and some well known scientist which will bring the project an external global viewpoint:

The PCC and the SC will meet at least twice a year at every general HIPPARCH meeting. If a PCC member can not attend a meeting, he may designate a replacement. Others may be invited to attend meetings, if all present agree. The Steering Committee will issue recommendations to the project that will be discussed within the PCC. Decision will be taken within the PCC on the basis of consensus.

A meeting has been organised June 10th, 1996, in Paris (hosted by DE). Steering Committee members participated to this first meeting.

The first mid­year meeting will be held at DE in Paris. The second mid­year meeting will be held at INRIA in Sophia­Antipolis. The first end­of­the­year workshop will be held at UU/SICS in Stockholm (first or second week of June 1997). The second end­of­the­year workshop will be held at UCL in London.

The industrial event is scheduled in December 1998 in Paris. Dassault Electronique is sponsoring the IP Future 98 Convention.

At the meetings visits and exchanges will be planned for the following half year and reports will be given about the visits in the past half year.

The requested funding for Management is described section 3.6.

The HIPPARCH results will be distributed to industry, academia and to standardization committees. We expect our research results to be directly applicable by our industrial partners.

The results will also be actively publicised within the scientific community, through articles, conferences, workshops, and at standard committee work groups. But we want to go beyond that point, we will also try to reach a larger audience, so that the results will eventually reach to the industry at large.

In this section, we also give some details on the expected benefit of the collaboration with UTS. It is not part of the academic take­up subsection because UTS collaboration will be both an added value from a scientific viewpoint and from an industry viewpoint, offering visibility to our partners on the Asian and pacific market.

The industrial supporters have expressed their interests for the project in a set of support letters and formal statements, which are summarised below:

• Ericsson Radio Systems AB, (ERA) will take up the results primarily through SICS since they already have established channels for technology transfers. Ericsson provides long term funding to SICS and they are within walking distance to each other which will facilitate informal exchanges. Furthermore, Ericsson and SICS already have common EC projects, such as the ACTS project "ON the MOVE" which also will facilitate the take up of results.

• Dassault Electronique (DE) is a full time partner in the project with the objective to take benefit of the HIPPARCH results for its future communication system developments.

• British Telecom (BT) is interested in the advancement brought by HIPPARCH to communication systems architecture. Instead of improving existing solutions, HIPPARCH choses to investigate new solutions based on novel communication architectures and new protocol mechanisms. BT will first use the results of HIPPARCH in their own development programs in order to fully evaluate their benefits to BT technology. This may result in inputs to standards bodies, and in integration to BT products. If the issues addressed in HIPPARCH are resolved successfully, BT will be able to offer significantly improved and more flexible network services enabling BT to offer a much broader range of user application tools.

The project members, together with their industrial supporters will organize, an event dedicated to the European industrial community during the second year of the project. The precise format of the event is not yet fixed. It could be a conference, a large demonstration, or a participation at an existing international or European event such as an exhibit. The results of this event will be reported in the final exploitation of results report (EER) to be delivered within two months after the end of the project.

There is no commercialisation plans in the project as most of the results will be prototypes, standardization action, software developments that will be made available to the scientific community, and with some restriction (agreement of our industrial partners), to other companies. In case of commercialisation, the intellectual property rights would be shared between involved partners.

To clarify the IPR situation in regard to the background material, a Memorandum of Understanding (MoU) is being signed by the HIPPARCH partners and Steering Committee members.

We plan the following dissemination activities during the project:

• More than 50 scientists from five continents attended both Hipparch workshop, organised in December 1994 (Sophia Antipolis) and December 1995 (Sydney) during the HIPPARCH EC­AUS activity. Building on this tradition, we will organize two more workshops during HIPPARCH. The initial results of HIPPARCH will be presented in 1996 in Sophia Antipolis, in co-operation with the IFIP International Workshop on Protocols for High Speed Networks (PfHSN '96). During the second HIPPARCH workshop, demonstration will be organised; and a particular effort will be made to associate European companies to this workshop.

• The results of the HIPPARCH EC­AUS activity have not only been publicised in dedicated workshops or journal issues, but also in leading networking conferences such as ACM SIGCOMM. The academic members of the project have a long tradition of publication in international journals such as "Transactions on Networking", "Computer Communication Review" or "Internetworking: research and experience". This is a very efficient way to publicise our research and to prepare the take up of the results by scientists and industry. A special issue of the "Journal on Selected Areas in Communications" (jsac) on HIPPARCH is already scheduled for early 1998. The guest editor of this special issue are HIPPARCH PCC members.

• UU will maintain a HIPPARCH Web server. This server contains all information relevant to the HIPPARCH activities; publications can be accessed; up­to­date information on the project results can be reached and workshops are advertised. The industrial partners Web servers will be connected to the HIPPARCH server.

• In addition to publications and conferences, we also disseminate our ideas through an exchange of researchers. European, North­American and Australian scientists have been visiting each other laboratories during the first 20 months of the HIPPARCH EC­AUS activity. We are already planning new exchanges for the HIPPARCH LTR project.

• The software tools and libraries designed in the project will be made available free of charge for the academic community. Licenses may also be granted to non­academic third parties, pending a case by case agreement from the HIPPARCH Steering Committee.

The standardization process varies with the standardization institutes, and also with the relative advancement of the various standardization projects. In the case of IETF, we will proceed by submission of internet drafts followed by open working group discussions. In other forum, we will submit memorandums through key players of existing working groups:

• Christian Huitema has been asked by Alison Mankin, the director of the transport area of the IETF, to chair a new IETF working group addressing the evolution of TCP. The initial results of HIPPARCH EC­AUS activity show that there could be beneficial to tailor TCP implementations according to application profiles. We will contribute to the TCPng working group with electronic message discussions and participate in their meetings.

• The Real­time Transport Protocol, RTP, can be seen as the basis for a new family of multimedia and multicast applications. We will specify the network consciousness in RTP by submitting an internet­draft to the Audio Video Transport working group of the IETF. We will also, in another draft, write an extension to RTP for the support of reliable or semi­reliable applications.

• Ericsson Radio AB and SICS will incorporate the results of HIPPARCH in their proposal of a standardized API for UMTS. This work will be performed in cooperation with the ACTS project OnTheMove, of which ERA is prime contractor and SICS a participant.

• Based on the HIPPARCH experience, we will write a document explaining how the principles of network consciousness can be used to simplify the handling of QoS parameters in the Internet. This document will be submitted as an internet­draft to the RSVP working group of the IETF.

• The application of network consciousness to simplify the handling of QoS will also be described in another memorandum, that will be submitted to the ATM Forum. John Adams of British Telecom, who is the convenor of the ATM forum working group on QoS, has been working with UCL on similar subjects since several years.

• Patrick Cocquet of Dassault Electronique is the editor of the multipeer taxonomy document prepared by the WG4 of ISO/JTC1/SC6. He will make sure that the results of HIPPARCH are taken into account in the new transport services and protocols defined by this working group.

• As the European pillar of the World­Wide­Web consortium, INRIA is in a very good position to contribute with the experiences of HIPPARCH into the design of the next generation Web protocols, and on the incorporation of real­time services in both the World Wild Web Consortium and the IETF.

It must be noticed that Christian Huitema departure from INRIA does not compromise the project activities in the IETF standardization activities. First Christian Huitema remains a Steering Committee member of HIPPARCH. Second Jon Crowcroft replaced Christian Huitema as a member of the IAB. Consequently, HIPPARCH activities will keep being tightly coupled with IETF activities.

To summarise, we will combine close co-operation with leading European industries, open communication with the academic community, and organised transfer of knowledge to the industry at large.

The Steering Committee (SC) will be following the project development and will control that the project research is going in the expected direction. It will give advice on scientific and technical evolution of the project with respect to the results expected by the industrial partners.

The SC consists of the PCC members, to which are added representatives from the other entities participating to the project, and some well known scientist which will bring the project an external global viewpoint:

External SC members have been chosen voluntarily out of Europe to increase the visibility of the project. These members are subject to change. The one cited in the table above already accepted to participate to the two reviews and to reviews the project deliverables.

The SC will meet at least twice a year at every general HIPPARCH meeting.

The Steering Committee will issue recommendations to the project that will be discussed within the PCC.

UTS intends to provide a significant contribution to the work of the HIPPARCH consortium informally. This will facilitate the continuation of the collaboration with HIPPARCH partners. The UTS work will be funded by ERICSSON and BT explicitly to facilitate this collaboration. Other funding could also come from the Australian government. But no funding will be required from EC for this collaboration.

The total resources committed by UTS for the related activities is 36 manmonths. UTS will provide its funding bodies the deliverables that have been agreed to, independently. However, UTS results, documentation and software will be made available to the HIPPARCH partners. It is anticipated this will improve our solutions and technical choices.

On some aspects, the collaboration will go a step further by actively working together especially on QoS management, traffic control, and experimentation. To this end we plan to have an exchange of researchers between UTS and the HIPPARCH partners (not funded by the project).

UTS will also advertise and disseminate the HIPPARCH results in Australia and in the Asian Pacific region.

The collaboration with UTS will have a direct influence on the following tasks. But the collaboration with UTS will not compromise the achievement of the HIPPARCH LTR project goals and results.

• Task 1.1 and 1.2. UTS will work on an alternate solution to the protocol compiler. This work will specifically study how protocols can be synthesised efficiently from an extended protocol library which was designed as part of the HIPPARCH EC­AUS activity. The proposal is to investigate ways of extending the concepts presented in [Abb93] to enable ILP techniques to be used within the automatically generated protocols, and how this will affect the resource management mechanisms being developed as part of an UTS independent activity and Task 3.1 in the proposal as described below.

• Task 2.2. UTS will be developing a QoS management framework for resource limited environments, extending their current work. The work will develop methods of detecting sustained QoS violations, and reasons for these violations by instrumenting a representative set of applications. The findings of this work will be directly relevant to the activities proposed in Task 2.2. Thus it is anticipated that Task 2.2 activities will be done in close collaboration with UTS.

• Task 3.1. As part of their QoS management work, UTS will be investigating the resources that need to be managed, and holistic scheduling schemes at the end system to integrate the management of these resources. This work will develop new scheduling schemes based on proportional resource management schemes such as stride [WW95]. The viability of the proposed schemes will be demonstrated through an experimental implementation of a the integrated resource management scheme. This work is very complementary to the activities of Task 3.1, and it is anticipated that this work will be closely synchronised.

• Task 4.3. The execution environments that will be developed as part of Task 3.1 and the related UTS activities will follow two different approaches. Thus it will be useful to evaluate, where possible, the performance of the demonstrator on the two different environments. Furthermore, inclusion of UTS in this activity will provide an environment in which there will be significant transmission delays and loss. Thus we propose to collaborate with UTS in developing the demonstrator application. Once more, UTS collaboration will not compromize the success of the WP 4 demonstrator.

There are 6 different types of periodic reports that will be delivered by the HIPPARCH project:

It will be the responsibility of the scientific manager to gather all the information necessary to prepare each report; except for the Consolidated cost statements (CSS) that will be prepared by INRIA.

Two main reviews will be organised during the project. They will be one day. The first review should be organised at the same time than the first workshop (end of the first year, in Stockholm). The second review should be organised simultaneously to the second workshop (end of the second year, in London).

An additional review could be organised for the extension period.

Steering Committee members will be invited to attend the reviews. In addition to the deliverable evaluation (through demonstration and/or presentation), The project partners will make a short presentation to describe their current situation in regards to exploitation and take­up of results (standardization, academic dissemination, industrial take­up).

During the reviews, time will be allocated to the Steering Committee (simultaneously to the reviewer discussion) to make its recommendation to the project partners.