HIPPARCH

 

Periodic Progress report

 

 

 

 

1.

Contents

1. *

1. *

Introduction *

2. *

First Year objectives and synthesis *

3. *

Project coordination and activities *

3.1 Travel, visits, and research STAFF exchanges *

3.2 International publications and events *

3.3 Technical achievement *

3.4 Meetings *

3.5 External collaborations *

4. *

INRIA Activities *

4.1 Introduction *

4.1.1 related activities *

4.1.2 deliverables *

4.1.3 resources *

4.1.4 deviation *

4.2 first year report *

4.3 Publications *

4.4 Future Activities *

4.4.1 Second year activities *

4.4.2 Deviation from the PP *

5. *

DASSAULT ELECTRONIQUE Activities *

5.1 Introduction *

5.1.1 related activities *

5.2 first year report *

5.2.1 Technical report *

5.2.2 resources *

6. UPPSALA UNIVERSITY Activities *

6.1 Introduction *

6.1.1 related activities *

6.1.2 ressources *

6.1.3 deviation *

6.2 first year report *

6.2.1 Work package 1 *

6.2.2 Work package 2 *

6.2.3 Work package 3 *

6.3 Publications *

6.4 Future activities *

7. *

SICS Activities *

7.1 Introduction *

7.2 Results *

7.2.1 Work Package 1: Automated generation and integration *

7.2.2 Work Package 2: Network conscious applications ; *

7.2.3 Work Package 3: Protocol support environment and resource management ; *

7.3 Deviations from the project work-plan *

7.4 Resources *

7.5 Travel *

7.6 publications *

8. *

UCL report *

8.1 Introduction *

8.1.1 Related Activities *

8.1.2 Deliverables *

8.1.3 Resource *

8.1.4 Deviations *

8.1.5 Analysis of Effect of work on future WP4 directions. *

8.2 UCL First Year report *

8.2.1 Multicast Transport Layer *

8.2.2 Application Modules *

8.3 Publications *

8.4 Future Activity *

8.4.1 Second year activities *

 

1.

Introduction

 

This document is the first annual progress report of the HIPPARCH project. HIPPARCH (HIgh Performance Protocol ARCHitecture) is the EC ESPRIT IT Long Term Research 21926. It began August 1996.

The project partners are:

Two major European companies, British Telecom (BT) and Ericsson Radio AB (ERA) are participating in the steering committee of the project. An additional steering committee member is UTS (University of technology Sydney), who is expected to become a project member before the end of the project.

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

 

This project extends the result of a previous HIPPACH EC-AUS activity, where the ALF based design has been validated, to the broadest possible range of information services and applications. The goal of the project is to study the benefit of the ALF and ILP principles for the design of communication systems supporting multicast, mobility and real-time media.

The project results are:

2.

First Year objectives and synthesis

 

The first year objectives are recapitulated in the following list of final deliverables. At the time of the review, all contracted work has been done. Final deliverables, as well as draft ones are available on the HIPPARCH project web site, http://www.docs.uu.se/hipparch/.

 

Task

Deliverable

Title

Authors

1.1

INRIA-1

Evaluation of the ALF Compiler

I. Chrisment, D. Kaplan, C. Diot

1.2

SICS-2

Integrated layer processing can be hazardous to your performance

A performance model for integrated layer processing

The applicability of integrated layer processing

B. Ahlgren, M. Björkman,

P. Gunningberg

B. Ahlgren

  1. Ahlgren, M. Björkman,

P. Gunningberg

1.2

INRIA-3

Prototype ILP Compiler

C. Diot, T. Braun

2.1

UU-1

Increasing communication performance by adaptive end-to-end compression in the transport layer

Forward error correction implemented in Java

B. Knutsson, M. Björkman

 

 

J. Arthursson

2.1

INRIA-4

Algorithms and protocols for network conscious applications

C. Diot, A. Seneviratne

2.2

INRIA-5

QoS model for network conscious applications

C. Diot, A. Seneviratne

3.

Project coordination and activities

 

This section gives a global view of the project and of the collaboration between partners.

 

3.1 Travel, visits, and research STAFF exchanges

Travel:

HIPPARCH partners have participated and contributed extensively to the IETF working groups. INRIA, UCL, DE, and SICS participated in all meetings. INRIA, UCL, and SICS are authors of RFCs and Internet Drafts. There are three IETF meetings per year. Last year’s meetings were in San Jose in December 96, Memphis in April 97, and Berlin in August 97. UCL, INRIA and DE are also active participants in IRTF’s Reliable Multicast Working Group. Jon Crowcroft is a member of IAB, and of the IRTF’s End to End research group, as well as a co-chair of two IETF Working Groups.

HIPPARCH partners are also Program Committee members in many International conferences and workshop, for example all partners participated in PfHSN held at INRIA in the Fall of 1996.

Christophe Diot and Jon Crowcroft participate to the COST 237 project (Multimedia Tele-services) and meetings, and their respective organisations are members of Cabernet. There were two meetings (including a workshop) during HIPPARCH project first year : Barcelona (workshop and meeting) in November 1996 and Milano (together with ECMAST conference) in May 1997.

Travel related to workshop and conference participation is detailed in the next section (2.2).

Visits, research staff exchanges :

There have been several examples of staff mobility within the HIPPARCH project. Long-term exchanges were mostly between UTS (Australia). Short-term visits are not detailed here; but they where required to co-ordinate the technical development in the project (UU-INRIA, UCL-INRIA, DE-UCL, INRIA-DE collaboration will be described in the technical achievement section).

It should be noticed that there are also frequent meetings between project participants in conferences, workshops, and IETF meetings. The project members have prioritised the visibility of the project over and above the internal exchanges. Project scientific mangers meet at least once per month in scientific events. Note that the project has also made extensive use of multimedia real-time conferencing for virtual meetings.

Research guests and visit outside the project will be described later in this report.

 

3.2 International publications and events

The following workshops have been organized by the HIPPARCH project members :

HIPPARCH members have also published (by paper selection or invitation) in the following events:

The HIPPARCH project was also editor of a special issue of IEEE Journal on Selective Areas in Communication (JSAC). This journal is one of the key « reference publications » in our research domain. Two papers of HIPPARCH passed the selection. 11 papers out of 50 will be published (publication scheduled for early 1998).

To conclude, here is a list of journals in which HIPPARCH members have published this year : IEEE Networks, IEEE JSAC, Distributed System Engineering.

It should be noticed that, among these publications, a large proportion involves two or more HIPPARCH project members.

 

3.3 Technical achievement

All project goals were achieved for this first year and significantly more resources were contributed by project partners than just that due in the project Programme. The details of resources expended in the project are given for each partner in later sections.

All deliverable have been published (or are being published) in international conferences, workshops, and journals.

But work has also started in other task, including:

These element will be integrated in the final architecture, during the second year of the project.

The collaboration aspect will be more important in the second year of the project. Recall that the project was organized in two parts:

 

3.4 Meetings

 

26 August 1996. Project meeting in conjunction with SIGCOMM '96 in Palo Alto, California, USA. This was the official project kick-off meeting.

31 October 1996. First project technical meeting was in conjunction with the IFIP PfHSN workshop (Protocols for High Speed Networks) at INRIA in Sophia-Antipolis, France.

3-4 February 1997. Second technical meeting and first management meeting at Dassault Electronique in Paris, France.

3 March 1997. Technical meeting at UCL in London, UK.

11-13 June 1997. Management and technical meetings and workshop in Uppsala, Sweden. Preparation of the review.

12 September 1997. First year review in Sophia Antipolis with the participation of the Steering committee members.

 

3.5 External collaborations

The HIPPARCH project has attracted the interest from various European and international companies :

 

We could also mention numerous academic collaborations in the US and in Europe that profit HIPPARCH : University of Massachussettes Amherst, UC Berkeley, Bellcore, UCLA, University of Paris 6 (LIP6), etc.

4.

INRIA Activities

 

4.1 Introduction

 

4.1.1 related activities

INRIA has contributed to the preparation of the IEEE JSAC special issue on Architectures for the 21st century.

Finally, INRIA prepared with UTS the appendix to the HIPPARCH Project program in order to associate UTS as a full partner of the HIPPARCH project.

INRIA has participated to all the IETF meetings (3 per year), and to the main scientific event in the research community (INFOCOM, SIGCOMM, and various workshops in the US and in Europe).

All the articles were presented by members of the rodeo project in the corresponding conferences and received good feedback from the reviewers, and good scientific evaluation.

 

4.1.2 deliverables

INRIA has 4 final deliverables that have been completed on time. (see section 2). Therefore, INRIA-4 (Algorithms and protocols for network conscious applications) needs to be enhanced with two appendices:

 

4.1.3 resources

Human resource per task :

Task 1.1 : 12 mm (INRIA local resource : 15 mm)

Task 1.2 : 12 mm (INRIA local resource : 12 mm)

Task 2.1 : 12 mm (INRIA local resource : 12 mm)

Task 2.2 : 6 mm (INRIA local resource : 16 mm)

Task 3.1 : 8 mm (INRIA local resource : 24 mm)

Total for the first year : 50 mm

 

The following people have participated to the project :

Diot 6 task 2.1 (3 mm), task 2.2 (3 mm)

Kaplan 10 task 1.1

Turletti 1 task 1.1

Chrisment 1 tasks 1.1,

Castellucia 2 task 1.2,

Brodard 10 task 1.2 (4 mm)

May 8 task 3.1

Gautier 12 task 1.2 (6 mm), task 2.1 (3 mm), task 2.2 (3 mm)

 

4.1.4 deviation

The tasks described in the PP have been completed with minimal changes. Detailed men-month allocation is described here before.

Therefore, a few minor changes have to be noted :

The resources allocated to the previous sub-tasks have all been consumed by the modification of the Esterel compiler to produce Java code. The original ALFred was planed to produced C code. For portability reason, we decided to move to Java (following a project meeting). This work was done partly with HIPPARCH project resources, and partly on RODEO project private resource.

The previously described changes do not modify the human resource balance.

 

4.2 first year report

 

During this first year of HIPPARCH, INRIA has been involved in the following tasks:

The prototype protocol compiler designed during the HIPPARCH EC-AUS activity has been extended with data manipulation functionality in addition to the event handling capability. Once operational, this protocol compiler has been evaluated with 3 different applications that have been specifically designed for this evaluation (the applications have been coded manually and automatically). The evaluation result is presented in deliverable INRIA 1. It confirms previously observed results.

The work on QoS positions the HIPPARCH project as a pioneer in the understanding and design of reactive QoS system (previous QoS systems were predictive). This work has led to a new collaboration between UTS and INRIA for the design of a QoS user manager based on the model defined during the HIPPARCH work. This work is funded separately by UTS. Our reactive QoS model is presented in the INRIA 5 deliverable.

The ILP compiler was designed first because of the need of a data manipulation engine required for the evaluation of the HIPPARCH EC-AUS activity prototype compiler. The ILP compiler did not show significant performance gains. We consequently decided not to use it in the ALFred compiler currently designed. The ILP compiler is described in deliverable INRIA 3.

This work allows us to clearly identify what should be the role of adaptation in a reactive QoS model. We have identified adaptation mechanisms that are embedded to the application that can be provided as a separate library, independently of the application characteristics. Together with the library of adaptation mechanisms (not yet implemented), we are providing a set of policies to understand when to use these mechanisms and how to switch these mechanisms dynamically in order to benefit the best possible QoS. We have also identified a very important element of QoS and adaptation that has not been studied up to today: monitoring. Deliverable INRIA 4 describes an adaptation model, together with a discussion on network monitoring.

A computer test-bed has been installed at INRIA to allow us to test our experimental Internet QoS infrastructure. Classic traffic control mechanisms have been implemented and evaluated (this is the object of the INRIA 6 draft deliverable). This classic infrastructure has shown to be too complex and not scaleable. We are now working on the implementation of the 1-bit QoS approach as defined by Clark and Crowcroft. Experimental results will be available for the final deliverable. Together with this traffic control implementation, INRIA has developed an IPv6 implementation with routing facilities where the traffic control infrastructure will be implemented soon.

Based on the knowledge acquired in HIPPARCH EC-AUS activity, we have started the design of a new protocol compiler which goal will be to be distributed for free before the end of the project. This new protocol compiler will be more robust, more powerful, and more flexible than the previous prototypes. It will provide a full environment for the design of formal application specification and for the automated generation of implementation. In addition to what is written in the Project program, ALFred will have the following features:

  1. ALFred now produces JAVA code in order to be OS independent
  2. Application profiles are being designed in order to simplify the task of the application designer. Profiles will be designed for Distributed Interactive application (providing DIS encapsulation), audio and video application, web data transfer.

Draft deliverable INRIA 2 is currently under design (technical report describing the design and the features of the new compiler).

It should be noted that we have been contacted by a private company (NORTEL) that wishes to fund parallel works based on ALFred to validate the feasibility in an industrial context and then to commercialise ALFred.

 

4.3 Publications

T. Braun and C. Diot. "Automated Code Generation for Integrated Layer Processing". IFIP workshop on Protocol for High Speed Networks. Sophia Antipolis (FRANCE). October 28-30, 1996.

C. Diot, W. Dabbous and J. Crowcroft. ``Group Communication''. IEEE Journal on Selected Area in Communication. Special Issue on Group Communication. May 1997.

C. Diot and A. Seneviratne. ``Quality of Service in Heterogeneous Distributed Systems''. Proceedings of the 30th Hawaii International Conference on System Sciences HICSS-30. Hawai. January 1997.

F. Gagnon and C. Diot. ``Impact of Out-of-Sequence Processing on Data Transmission Performance''. INRIA Research Report RR-3216. INRIA Sophia Antipolis (France). July 1997.

M. May and C. Diot. ``An experimental Implementation of traffic Control for IP Networks''. IEEE HPCS workshop. Chakildiki (Greece). June 1997.

  1. Chrisment, D. Kaplan, and C. Diot. ``An ALF Comunication Architecture: Design and Automated Implementation''. To be published in the IEEE JSAC Special Issue on Architectures for the 21st century. 1998.

 

4.4 Future Activities

4.4.1 Second year activities

Most of the work to be done in HIPPARCH was centered on the first year of the project. Remaining tasks for INRIA are :

Task 1.1 The ALFred compiler

We will complete the protocol compiler as defined in the PP, with modifications described in section 3.1.4. The ALFred compiler will be made available at the end of the project to the scientific community, and 6 months before the end to the project members and Steering Committee members.

Task 3.1 Application-to-application resource scheduling and management

After having implemented a full resource management environment for IP, we are now working on light trafic control and signalling mechnaisms based on the 1-bit QoS approach defined few years ago by Clark, and which is very popular in the Internet.

Task 3.3 Integration with ALFred

This work, done in collaboration with UU, will permit to integrate the resource manager designed by UU to the protocol compiler in order to be able to take advantage of the monitoring facilities provided by the UU environment to adapt more efficiently at the application level.

Task 4.3 Automated generation of HTTPng comunication subsystem and comparison with handcraft system.

In this task, the role of INRIA will be to help in specifying the formal application in Esterel, and to enhance the protocol compiler with any (possibly) missing communication blocks (specific to the demonstration application or to HTTPng).

INRIA also intends to design before the end of the project a full QoS architecture which elements will be :

 

4.4.2 Deviation from the PP

Again, deviations from the PP are minimal and they mostly concern the ALFred compiler :

We will prefer a Java stub compiler to our ILP compiler (justified in 3.1.4)

The optimisation tool we have designed for ALFred is now useless (because of the Java modifications). Optimisation was possible on automatons generated by the Esterel compiler. We discovered that the complexity of these automaton are such that we decided to move to another version of the Esterel compiler that generates circuits instead of automatons. These circuits are much more optimal, and the Java code is generated from this circuit description. The circuit options gives us more optimal code from a Java viewpoint ; but it makes obsolete the optimisation tool we have designed.

Again, we do not expect any change in the ressource allocation for the second year of the project.

5.

DASSAULT ELECTRONIQUE Activities

 

 

5.1 Introduction

Dassault Electronique, as the industrial partner, is mainly involved in the evaluation phase of the project which is focused on the second year of the project. DE is the leader of the work package 4 « Demonstration based on the World Wide Web ».

 

5.1.1 related activities

Dassault Electronique, which is the industrial working partner within the HIPPARCH consortium, contributed to the task WP2, with about 0.7 man year per year, mainly involved on the 4 last months of the period.

Actually, most of the integration work planned for this period has been done. Some delays occured due to unplanned efforts provided to turn in profits HIPPARCH works in including current results in new products, projects or proposals. (see below at dissemination activity)

During this first year of the project, two D.E. engineers have participated in the IETF Working Groups dealing with IPng, RSVP and the Integrated Services. DE is also involved in the new IRTF working group on Reliable Multicast.

The results of the Freephone integration are being used to design a commercial offer suited to the current multimedia environment.

First components of the MUSICA family are dedicated to the audio world. They will be demonstrated during the next InterOp 97, which will be held in Paris on the 21-23 of October 1997. The video components should be available before the end of 1997.

Performance measurements should be conducted soon, and results will be gathered within a document issued as part of the HIPPARCH deliverables.

Partners coordination:

Although not directly implicated in all developments produced during the first year, Dassault Electronique attended each technical meeting organised by the HIPPARCH partners, whatever subject they dealt.

Dassault Electronique is mainly involved in the evaluation phase of the project which is focused on the second year of the project. For this reason, D.E. has interest in being aware of each new orientation .

Moreover, co-ordination meetings with the project managers allowed to define a first definition of the demonstration and evaluation platforms. New meetings are already planned to tune and refine this definition, taking into account the intermediate results of the project.

Technical Management:

D.E. is collecting the first releases of the prototype software from the academic partners as soon as made available.

D.E. has agreed the different revisions, evolutions or deviations that are submitted by the contractors to the approval of the « Commission of the European Communities ».

Organisation of events:

The marketing campaign for the first audio products of the MUSICA family ( MUSICA-IP and MUSICA-VIP) should be launched in a near future (mid of october). For this occasion, the components will be proposed for a free evaluation.

Some significant companies or organisations such as EUROCONTROL, FRANCE TELECOM and NATO are taking a keen interest in the products and are requesting to be part of the evaluation process.

 

5.2 first year report

 

 

 

5.2.1 Technical report

During the first year of the project, DE has worked on two areas of the work package 2 related to « network conscious applications».

 

5.2.2 resources

 

 

 

 

 

Human resource per task :

Management: 1mm

Task 2.1 : 4 mm (D.E. local resource : 4 mm)

Task 4.3 : 1 mm (DE local resource : 1mm)

Total for the first year : 6 mm

 

The following people have participated to the project :

Cocquet 0,7 Management

Lenglet 0,3 Management

1,2 task 2.1 (Analysis of the QoS mechanisms)

Falquet 1,4 task 2.1, (Evaluation of adaption algorithms within Freephone))

Lecanuet 1,4 task 1.2, (Technological analysis of Freephone for the demonstration)

Cathelin 1 task 4.3 (Platform configuration for the demonstration)

 

Project Meeting Attendance

 

- Project meeting 970203-04 at Dassault in Paris, France. Patrick Cocquet and Philippe Lenglet attended.

- Project meeting 970303 at UCL in London, UK. Patrick Cocquet and Philippe Lenglet attended.

- Project meeting and workshop 970611-13 in Uppsala, Sweden. Philippe Lenglet attended.

 

 

 

 

 

 

6. UPPSALA UNIVERSITY Activities

 

6.1 Introduction

Uppsala University (UU) is a full time partner within HIPPARCH project and contributes with about one and a half man year per year. The work has proceeded as planned. Actually, we have achieved more than planned in some tasks due to synergy effects with other projects. Staff and cost of the project are reported elsewhere.

6.1.1 related activities

 

 

6.1.2 ressources

UU manpower distribution for results delivered:

WP Planned Actual Contribution UU Contribution Telenor Research

1.2 5 5 - -

Per Gunningberg (3), Mats Bjorkman (3)

2.1 3 5 2 -

Mats Bjorkman (2), Bjorn Knutson (5)

3.1 9 12 1 5

Per Gunningberg (2), Gordon beaton (6), Jochen Schiller (2), Johan Arthursson (3)

Mgm 1 1 - -

Per Gunningberg (1)

--------------------------------------------------------------------------------------------------------------------

Total 18 23 3 5

 

UU has spent more time and achieved more than planned. This is primarily due to the fact that a very competent Post Doc (Jochen Schiller) worked in the project and that we have been able to find synergy effects with other projects.

 

6.1.3 deviation

No problems or deviations. Results are in accordance with manpower spend on WP.

 

6.2 first year report

Our scientific work has been carried out in work packages 1, 2 and 3. UU is work package leader for number 3. Summary of major technical achievements during the period :

 

 

6.2.1 Work package 1

In WP 1 UU has contributed to the task « ILP compiler », i.e. the SIC-2 deliverable « Performance Effects of CPU Register Usage for Integrated Data Manipulation Functions ». See SICS-2 for further details. This work resulted in a PhD exam.

 

6.2.2 Work package 2

UU contribution in WP, Network Conscious applications, is in the task « Algorithms for Network Consciousness ». The deliverable UU-1, is on « Trade-offs between computing and resources ». We have focussed on trade-offs on slow links with lossy behaviour e.g. wireless links. Five man-months was allocated to this task. We did indeed spend more time on this task than anticipated, partly due to a master Thesis work and general UU support to graduate students. Two activities has been completed and resulted in two publications which comprise the deliverables UU-1 :

The first one is on trade-offs between compression of data for shorter bulk transfer time versus the delay for initiating a compression, CPU cycles required and rate of underlying link. Different algorithms are implemented and measurements over various links have been performed. The deliverable is found in Annex I.

The second activity is on trade-offs using Forward Error Correction code. A Java implementation of FEC is implemented and the idea is to initiate or download the appropriate level of FEC for a lossy link. Measurement has been performed. The code has been released to Eurecom (Biersack/Carle). The result are summerized below.

 

6.2.3 Work package 3

This is the major work package for UU. The title is « Protocol support environnment and resource management ». The intent of this WP is to investigate resource management mechanism and policies for end systems according to a QoS contract and network conscious applications with real time requirements. Prototypes will be implemented and evaluated. An API for access and user control of resources user level protocol and applications will be implemented.

The work at UU has focussed on two activities of en system resource management. The first is a novel scheduling CPU principle. Instead of statically allocate CPU cycles to the application we propose a feed-back loop that allocates resources according to a user preferred value. It was observed that traditional static resource allocations tend to be very complex and that the resources were typically overallocated in order to meet the worst case or due to uncertainties. Furthermore, the amount of cycles depend on the machine and may also be data dependent which make an accurate allocation even more unreliable.This work has mainly been carried out together with UTS, at UTS of a visiting UU staff member.

The second activity on end system resources is on network adapter scheduling. The major result is the demonstration that a CPU based approach can be used to do co-scheduling of traffic shaping and DMA transfers of a large number of independant high speed connections. This work is carried out in co-operation with Telenor Research in Norway.

 

6.3 Publications

 

6.4 Future activities

The effort from UU for the next year will, according to plan, be in WP 3 and a small part of WP 4, on the overall integration.

The objective of our work in WP 3 is to investigate overall scheduling in the end system. So far we have separately studied CPU scheduling and scheduling in a network adapter. Both are based on variants of rate scheduling. We will continue to study how the interconnect bus can be scheduled. In particular the rate based approaches proposed by MIT are of interest. Our hypothesis is that all these schedulers eventually could be co-ordinated for increased efficiency and predictable behaviour.

The investigation into the feed-back CPU scheduling principles (based on the Stride Scheduler) will continue in co-operation with UTS. This work is implemented in the Linux kernel.

Resource reservation and control in Unix for application protocols is cumbersome. We have to modify the kernel, the APIs and drivers for our experiments. The Exokernel approach from MIT offers an attractive alternative with exported low level abstractions and user level OS libraries. These libraries can be modified for communication software needs without compromising secure multiplexing of resources. We have a contact with MIT and the only Exokernel (XOK/Aegis) running outside MIT. For this project we intend to compare the Exokernel way of resource management and protocol execution environment with the traditional Unix Way.

The mobile and wireless environment is of increasing interest for real-time communication services. Within this work package we will consider the special need of this environment for application-to-application resource management to a larger extend than originally planed. A demonstrator testbed for experiments will be extended at UU and UTS.

At an overall view, the UU tasks are on schedule and there are additional results thanks to synergy effects.

 

7.

SICS Activities

 

7.1 Introduction

SICS is an associated partner to Uppsala University in HIPPARCH. SICS' effort in the project is one man-year per year. Most of the work has been done in close collaboration with Uppsala University.

During the first year of the project, SICS' main effort has been in Work Package 1 (T1.2), which has resulted in deliverable SICS-2, a PhD thesis and two presentations at international conferences. The work performed in Work Package 2 (T2.1) has resulted in an Internet Draft document within the IPNG working group of the IETF.

SICS also participated in the arrangement of the HIPPARCH'97 workshop in Uppsala in June 1997 as well as in the reviewing process for a special issue of the IEEE Journal on Selected Areas in Communications.

 

7.2 Results

 

      1. Work Package 1: Automated generation and integration
      2. Task 1.2: The ILP compiler

        The work in this task resulting in deliverable SICS-2 is largely joint work with the Dept. of Computer Systems at Uppsala University, Sweden, as shown by the respective authorships of the publications below. The deliverable SICS-2 consists of three publications which are supplied as annexes to this document:

        Title: Integrated Layer Processing Can Be Hazardous to YourPerformance

        Authors: Bengt Ahlgren, SICS; Mats Björkman and Per Gunningberg, UU

        Title: A Performance Model for Integrated Layer Processing

        Author: Bengt Ahlgren, SICS

        Title: The Applicability of Integrated Layer Processing

        Authors: Bengt Ahlgren, SICS; Mats Björkman and Per Gunningberg, UU

        The research results included in this deliverable is also a significant part of Bengt Ahlgren’s doctoral dissertation [4]. The three publications are summarised in the following paragraphs.

         

        Integrated Layer Processing Can Be Hazardous to Your Performance

        Integrated Layer Processing is a protocol implementation technique which purpose is to reduce the number of memory references to message data, and thus increase communication throughput. In this publication we report on an experimental study of how the total number of memory references is affected by integration of data manipulation functions with varying characteristics.

        The main result is that the relationship between the number of available processor registers and the aggregated state size of the data manipulation functions is crucial for the resulting communication throughput. When the aggregated function state size does not fit in processor registers, the integrated implementation will introduce additional memory references to function state. In many circumstances the saved memory references to message data are fewer than the additional memory references to function state resulting in an increase of the total number of memory references and thus reduced communication throughput.

         

        A Performance Model for Integrated Layer Processing

        This paper presents a performance model for integrated and sequential implementations of data manipulation functions. It is a direct continuation of the work in the paper above.

        The purpose with the model is to better understand the complex relationship between different parameters and the performance of the integrated and sequential implementations. In particular, I wanted to better understand the situation when the function state overflows the processor registers. The purpose is also to be able to predict the performance before choosing implementation technique and starting a possibly expensive implementation project.

        The goal of the performance model is to accurately model the register, cache and memory behavior of the sequential and integrated implementations of a set of data manipulation functions. The core of the model therefore predicts the memory accesses to function state that does not fit in registers and to message data for the two implementation techniques. The memory accesses to function state is computed from the state sizes defined by the function parameters and from the available processor registers. The model is verified against real measurements. The predicted performance from the model compare well with the measured performance.

         

        The Applicability of Integrated Layer Processing

        This paper summarises our research on Integrated Layer Processing. It also gives an overview of other researcher's work in the area.

         

      3. Work Package 2: Network conscious applications ;
      4. Task 2.1: Algorithms for network consciousness

         

        SICS' work in this task has been on adaptation for wireless links using protocol header compression. The work has been done in collaboration with Luleå University and is only partly supported by the HIPPARCH project.

        The IP Header Compression draft is now in its 3rd version and it is entitled draft-degermark-ipv6-hc-03.txt [5]. The draft has gone through Working Group Last Call in the IPNG (IP Next Generation) Working Group of the IETF (Internet Engineering Task Force) and will be recommended to the IESG (Internet Engineering Steering Group) who will consider the draft after making a Last Call for the status of Proposed Standard RFC. During this period interworking experiments between different implementations of the draft will take place and the results made public. The final step will be, hopefully, an Internet Standard RFC on IP Header Compression.

        At the time of writing, there are two implementations of IP Header Compression in commercial and public domain operating systems: Sun Solaris and NetBSD. We are also hopeful of getting an implementation in a predominantly PC-based OS.

         

      5. Work Package 3: Protocol support environment and resource management ;

Task 3.1: Application-to-application resource scheduling and management and Task 3.2: An experimental API supporting protocol modules built with ALFred

 

The work in these tasks have been started with discussions on QoS architecture with the project partners.

We are also currently discussing modifications these tasks to better support the demonstrations in work package 4.

 

7.3 Deviations from the project work-plan

 

The work has progressed according to the project work-plan with the following exceptions:

 

 

7.4 Resources

Man-months

Person T1.2 T2.1 T3.1 T3.2 Total

--------------------------------------------------------------------------------

Bengt Ahlgren 7.2 1.5 0 8.7

Stephen Pink 3 3

--------------------------------------------------------------------------------

Total 7.2 3 1.5 0 11.7

--------------------------------------------------------------------------------

Planned 6 5 1.5 1 13.5

 

7.5 Travel

 

SICS has participated in the following project meetings and workshops. If not otherwise noted, Bengt Ahlgren participated.

 

- Project meeting 960826 in conjunction with SIGCOMM'96 in Palo Alto, California, USA. Bengt Ahlgren and Stephen Pink participated from SICS. (The travel cost is not paid by the project.)

- Project meeting 961031 in conjunction with the IFIP PfHSN conference at INRIA in Sophia-Antipolis, France.

- Informal HIPPARCH workshop 961108 at Ericsson Radio in Kista, Sweden.

- Project meeting 970203-04 at Dassault in Paris, France.

- Project meeting 970303 at UCL in London, UK.

- Project meeting and workshop 970611-13 in Uppsala, Sweden.

 

7.6 publications

 

[1] Bengt Ahlgren, Mats Björkman, and Per Gunningberg. Integrated layer processing can be hazardous to your performance. In Fifth IFIP Workshop on Protocols for High Speed Networks (PfHSN '96), pages 167-181, Sophia-Antipolis, France, October 28-30 1996.

[2] Bengt Ahlgren. A performance model for integrated layer processing. In Seventh IFIP Conference on High Performance Networking (HPN '97), pages 249-264, White Plains, NY, USA, April 28-May 2, 1997.

[3] Bengt Ahlgren, Mats Björkman, and Per Gunningberg. The applicability of integrated layer processing. IEEE Journal on Selected Areas in Communications, 1998. To appear.

[4] Bengt Ahlgren. Improving Computer Communication Performance by Reducing Memory Bandwidth Consumption. PhD thesis, Uppsala University, Uppsala, Sweden, March 1997. DoCS 97/80, ISSN 0283-0574. Also as SICS Dissertation Series 24, ISSN 1101-1335.

[5] Mikael Degermark, Björn Nordgren, and Stephen Pink. Header compression for IPv6. Internet Draft, July 1997. draft-degermark-ipv6-hc-03.txt.

 

 

 

8.

UCL report

 

8.1 Introduction

UCL, as a project partner, during the past year activity was in charge of task WP4.1 (Application Specification) and task 4.2 (Hand Crafted HTTPng Communication Subsystem) of the Working Package 4 (Demonstration based on the Work Wide Web).

At the present time both the task are in an advanced state of completion, WP4.1 having identified and analysed interesting proprieties and requirements in Web-based client server application; and WB4.2 having provided a number of building block for the applications. All above will be detailed in the next section.

 

8.1.1 Related Activities

UCL people have actively participated to the activity of the Reliable Multicast IRTF Working Group (attended meetings, taking minutes, giving talks). They also have attended and co-chaired (Jon Crowcroft) Large Scale Multicast Applications and Inter-Domain Multicast Routing Working Groups of IETF.

 

8.1.2 Deliverables

2 draft deliverables are available on the project Web :

 

      1. Resource

Staff Resources

The following people have worked on the HIPPARCH project (for each of them, the number of mm, and a short description of the work done is given).

Zheng Wang – 4.1 Application Set Specification 6 months

responsible for first draft deliverable.

Lorenzo Vicisano/Paul White/Philippe Oechslin – 4.2 «Hand Crafted HTTPng Communication subsystems – 9 months

responsible for 2nd draft deliverable, and demonstration at annual project review.

Steve Davey – Web Service and Multicast Routing Configuration for experiments – 3 months.

Project Meetings

- Project meeting 960826 in conjunction with SIGCOMM '96 in Palo Alto, California, USA. Jon Crowcroft attended

- Project meeting 961031 in conjunction with the IFIP PfHSN conference at INRIA in Sophia-Antipolis, France. Jon Crowcroft attended

- Project meeting 970203-04 at Dassault in Paris, France. Jon Crowcroft and Zheng Wang attended.

- Project meeting 970303 at UCL in London, UK. Jon Crowcroft and Lorenzo Vicisano attended.

- Project meeting and workshop 970611-13 in Uppsala, Sweden. Jon Crowcroft and Lorenzo Vicisano attended.

 

8.1.4 Deviations

In the process of finding the most interesting aspects of HTTP modifications, to allow the usage of other transport protocol beside TCP, UCL has identified the interaction between HTTP and multicast data delivery as one of the more difficult challenges.

For this reason, and for the lack of any general solution for multicast data delivery, UCL has moved most of its effort from HTTPng generalities to adaptation of HTTP to multicast transport protocols and to the analysis of suitable multicast protocols themselves.

There are no consequences for the work packages in year two as a result of this shift, since it essentially represents a change in the way that we integrate HIPPARCH protocols with Web Technology. Instead of re-engineering HTTP per se as a specific protocol framework, we provide a wrapper via Java proxies at the client and server sides, thus actually making it potentially easier rather than harder to carry out the comparison work in WP4.3. It will also allow us to make useful synergies between the HTTPng framework of Java proxies, and the new Java output from the INRIA ALFred compiler.

8.1.5 Analysis of Effect of work on future WP4 directions.

The replacement of the actual protocol changes to HTTP, with a framework based around Java applets should not make any change to the collaboration, since this is simply how the novel application and their novel protocols systems are initiated, and not how they subsequently behave. Indeed, it should be very simple to dynamically select either a manual or automatically derived protocol stack, with our Java framework, this making the last states of the project actually easier than if we had integrated the protocols into a specific, potentially monolithic HTPng system (i.e. if we had copied the tight integration and dependence of HTTP 1 and HTTP 2 on TCP, and fallen into the same trap that the current HTTPng designers find themselves in, with a lot of difficulty in unravelling!).

The RMFP framework which is used to implement the reliable multicast protocol, should allow a clean seperation of the data format specification (need for the INRIA ALF compiler work) from the protocol actions. We belive that the comparison of our manual reliable multicast protocol with an automatically derived one, together with an RTP based protocol that is used in Freephone and Rat, and the manual and automated versions of the protocol used in MiMaze, should provide three widely separated data points in the design space.

 

8.2 UCL First Year report

According to the specifications of Work Packages 4.1 and 4.2, UCL has terminated the Application Set Specification and is involved in the task of implementing the Hand Crafted HTTPng Communication Subsystem.

In both the activities has been put much effort in exploiting effectively the Multicast paradigm as the underline transport layer both for bulk-data transfer and for multimedia stream, whenever possible.

Multicast delivery is not a very well deployed technology, and its usage introduces several problems not present in the unicast communication paradigm. Peculiar issues in multicast delivery include: establishing and maintaining information on the participants (membership issues), synchronising participants, providing scalability with the respect of the number of participants. Because of the latter issue, requirements such as reliability and congestion control cannot be solved using the classical approaches used in unicast protocols.

For example it is widely recognised that reliable multicast is considerably more complex than reliable unicast. In particular, it is difficult to build a generic reliable transport protocol for multicast, much as TCP is a generic transport protocol for unicast. Multicast is a case where "one size fits all" does not work at all. Applications often have very different reliability and latency requirements, state management styles, error recovery and group management mechanisms. A reliable multicast transport protocol that meets the worst-case requirements is unlikely to be efficient and scalable for many application requirements.

In our protocol design we have faced the heterogeneity problem by specifying a common framework for building a family of different reliable multicast applications, instead of trying to design one generic reliable multicast protocol for all applications (see [1]). According to it we have split all the functionalities required into two logical layers:

1) A core transport layer, which provide congestion control and ---if needed--- reliability, preserving scalability.

2) Application-level modules providing out-of-band functionalities (synchronisation, membership establishment). This layer has been designed in web client/server applications.

 

8.2.1 Multicast Transport Layer

The core multicast transport layer has been designed and simulated as a part of the activities concerning WP4.1. Successively it has been implemented and evaluated as part of WP4.2. See [2,3,4].

The main functionality provided by this layer is congestion controlled. It uses an algorithm suitable for cumulative, layered data streams in a packet switched best effort network (such the MBone). This algorithm behaves similarly to TCP congestion control algorithm, and shares bandwidth fairly with other instances of the protocol and with TCP flows. It is entirely receiver driven and requires no per-receiver status at the sender, in order to scale to large numbers of receivers.

It does not require additional router support other than pruning, and is suitable for bulk data transfer and continuous data streams.

When required, this transport layer can provide reliability in a fully scalable manner. This functionality is obtained by means of FEC techniques. Namely we use block redundancy codes to spread the information being transmitted in a very large number of packets. Each packets carries information on all the data being transmitted, so that, in principle, the reception can be accomplished by collecting a given number of different packets, no matter which they are. This way of operating eliminates explicit feedback to the sender and allow full scalability.

The multicast transport layer has been implemented as a user level library that can be linked to the application programs. Both during the setup phase and at runtime, application can negotiate the transport parameters (including packet size and data rates). ALF guidelines has been followed implementing this features and leaving to the application level all the functionalities which are more application dependent.

 

8.2.2 Application Modules

Our implementation is based on two Java standalone modules: a client, that act as a proxy server for a usual Web browser; and a server. Each transaction starts with an usual http request from the standard browser to our client. The transaction then evolves either in the usual way (http-wise), if the requested object has to be transferred in a normal http-over-TCP way, or turns up to a request from the browser to our proxy-client, if a multicast transport protocol is selected. This is obtained by means of an http-redirect reply.

In the latter case the object is transferred between our customised client and server using multicast, and the http-redirect message carries the needed parameters. Two multicast transfer modes are allowed: a poll mode, and a continuous mode. In the former the object is transferred on-demand and the server possibly performs receiver aggregation (waiting for a given number of request before transferring the object). In the latter the object is continuously transmitted, and the initial request is mainly for retrieving the needed reception information (e.g. group address). The continuous mode is mainly suitable for continuous media streams (e.g. video/audio).

 

8.3 Publications

[1] Zheng Wang, Jon Crowcroft, Christophe Diot, Atanu Ghosh, ``Framework For Reliable Multicast Application Design '', internet-draft presented at RM meeting of IETF in Memphis IETF.

[2] L.Vicisano, J.Crowcrof, ``One to Many Reliable Bulk-Data Transfer in the MBone'', Proc. Of HIPPARCH '97 the Third International Workshop on High Performance Protocol Architectures, Uppsala, Sweden, June 12-13, 1997.

[3] L.Rizzo, L.Vicisano, ``A Reliable Multicast data Distribution Protocol based on software FEC techniques'', The Fourth IEEE Workshop on the Architecture and Implementation of High Performance Communication Systems (HPCS'97) Sani Beach, Chalkidiki, Greece June 23-25, 1997.

[4] L.Vicisano, L.Rizzo, J.Crowcroft, ``TCP-like congestion control for layered multicast data transfer'', University College London, 1997, Research Report, submitted for reviewing.

[5] Z. Wang, J. Crowcroft . CacheMesh: A Distributed Cache System For World Wide Web RN/97/23, May 1997, Submitted to Web Cache Workshop'97

[6] B. Carpenter, J. Crowcroft. Prospects for Internet Technology RN/97/52 June 1997 Distributed Systems Engineering, vol 4 1997, pp 78-86, 0967-1846.

 

8.4 Future Activity

8.4.1 Second year activities

Close Collaboration with INRIA on Automatic Generation of same as we have demonstrated. (WP 4.3 - main task for year 2) and with Dassault Electronique on the final demonstrator/integration.

Analysis of Effect of work on future WP4 directions. The replacement of the actual protocol changes to HTTP, with a framework based around Java applets should not make any change to the collaboration, since this is simply how the novel application and their novel protocols systems are initiated, and not how they subsequently behave. Indeed, t should be very simply to dynamically select either a manual or automatically derived protocol stack, with our java framework, this making the last states of the project actually easier than if we had integrated the protocols into a specific, potentially monolithic HTPng system (i.e. if we had copied the tight integration and dependence of HTTP 1 and HTTP 2 on TCP, and fallen into the same trap that the current HTTPng designers find themselves in, with a lot of difficulty in unravelling!).

The RMFP framework which is used to implement the reliable multicast protocol, should allow a clean separation of the data format specification (need for the INRIA ALF compiler work) from the protocol actions. We believe that the comparison of our manual reliable multicast protocol with an automatically derived one, together with an RTP based protocol that is used in Freephone and Rat, and the manual and automated versions of the protocol used in MiMaze, should provide three widely separated data points in the design space.