ALFred, an ALF/ILP Protocol Compiler for Distributed Application Automated Design.

92 Pages·2007·0.22 MB·English

INSTITUT NATIONAL DE RECHERCHE EN INFORMATIQUE ET EN AUTOMATIQUE
ALFred, an ALF/ILP Protocol Compiler for
Distributed Application Automated Design.
Torsten Braun, Isabelle Chrisment, Christophe Diot, François Gagnon,
Laurent Gautier, Philipp Hoschka
N˚ 2786
January 1996
PROGRAMME 1
Architectures parallèles, bases de don-
nées, réseaux et systèmes distribués
(cid:13)
apport
de recherche(cid:13)
(cid:13)
9
9
3
6
9-
4
2
0
N
S
S
I

ALFred, an ALF/ILP
Protocol Compiler for
Distributed Application
Automated Design.
T. Braun, I. Chrisment, C. Diot, F. Gagnon,
*
L. Gautier, P. Hoschka
Programme 1: Architectures parallèles, bases de données,
réseaux et systèmes distribués
Projet Rodeo
Rapport de recherche n˚2786- January 1996
90 pages
Abstract: This report describes the design and the prototyping of a compiling tool
for the automated implementation of distributed applications: ALFred. This com-
piler starts from the formal specification of an application written in ESTEREL, and
then integrates end-to-end communication functions tailored to the application char-
acteristics (described in the specification) and produces a high performance imple-
mentation. The report describes tdescribes the communication architecture asso-
ciated to our automated approach. The compiler is made of two main parts: a con-
trol compiler also called ALF compiler; and a data manipulation compiler (the ILP
compiler) that combines data manipulation functions in an efficient way (the ILP
loop). The ALFred compiler has been designed to allow the development and the
analysis of non-layered high performance communication architectures based on
ALF and ILP.
Key-words: High Performance Protocol Architectures, Formal Description, Tai-
lored Protocols, End-to-End Control, ALF, ILP, Multimedia Applications.
(Résumé : tsvp)
*Email: [email protected]
INSTITUT NATIONAL DE RECHERCHE EN INFORMATIQUE ET EN AUTOMATIQUE
Unité de recherche INRIA Sophia Antipolis :2004, route de Lucioles-B.P. 93-06902 Sophia Antipolis cedex (France)
Téléphone : [phone] - Télécopie : (33) 93 65 77 65 - Télex :970050 F
Établissement public national à caractère scientifique et technologique - Décret No 85.831 du 2 août 1985
ALFred, un Compilateur
de Protocoles pour
l’Implantation Integree
d’Applications
Distribuees.
Résumé : Ce rapport decrit la conception et le prototypage d’un compilateur pour
l’implantation automatisee des applications distribuees: ALFred. Ce compilateur
utilise la description formelle d’une application ecrite en ESTEREL, ainsi que la
description en C des donnees traitees par l’application; il y integre des modules de
communication (pour le controle de bout en bout) choisis selon les caracteristiques
de l’application avant de produire automatiquement une implantation hautes perfor-
mances. Le rapport decrit tout d’abord la maniere dont les applications doivent etre
specifiees afin d’etre utilisables efficacement par le compilateur. Le compilateur se
compose de deux parties: un compilateur de controle et un compilateur de manipu-
lation de donnees. ALFred a ete concu pour permettre le developpement et l’analyse
d’architectures de communication hautes performances ne s’appuyant pas sur une
organisation en couche.
Mots-clé : Architectures de Communication Hautes Performances, Techniques de
Description Formelles, Protocoles Dedies a l’Application, Controle de bout en bout,
ALF, ILP, Applications Multimedia.
ALFred, an ALF/ILP Protocol Compiler for Distributed Application Automated Design. 3
1 Introduction
The lack of flexibility and efficiency of the traditional generic and layered commu-
nication model has led to consider new approaches when designing communication
subsystems. The lack of flexibility is due to the difficulty for the generic subsystems
to meet the specific needs of the new applications. RPC, for example, is presently
the most world-wide used paradigm to develop distributed applications. However,
RPC presents some limits: as it is based on the request/response protocol, RPC is
not adapted for multimedia and time constrained applications. The lack of efficiency
is induced by generality. Some redundant or useless functionalities are implemented
within the generic subsystems in order to be able to satisfy every possible types of
applications.
Another approach is emerging which consists of implementing protocol subsystems
tailored to application requirements. According to this approach, we believe that the
application communication requirements can be expressed by using a formal lan-
guage. The formal method is a way to allow the implementation to mach exactly
with the application needs. It is also an approach to the design of complex commu-
nication system which cannot be designed by hand.
The ALFred protocol compiler provides an environment for the design and the veri-
fication of reliable data transmission over communication networks. It addresses
specifically the automated integration of end-to-end transmission control function to
distributed applications. In its final form, ALFred will automatically design client-
server executable programs starting from an application formal specification written
in ESTEREL language for its control part, and in C for data description.
The goal of ALFred is to investigate new communication architectures based on ALF
an ILP rules [Clark90]. The ALF rule says that the unit of control should be the unit
of transmission. This property can be guaranteed at least at the end-to-end level. But
there is no control on this while on the network. The ILP rule says that all data ma-
nipulations should be made in one loop, in order to reduce to one the data read/write
operations which are known to be the most expensive in protocol operations. Previ-
ous studies [Chrisment94][Braun95a][Diot95][Roca96] showed that ALF and ILP
will provide significant gains only if the protocol architecture is «adapted», i.e no
segmentation, flat header structure (no layered architecture), process data on the
same elementary unit (which should be a multiple of the bus size). Because of the
high level integration of the application with its end-to-end control facilities, a formal
design in an automated framework is the only credible approach to the design of this
type of communication architecture.
ALFred operates in three steps (figure 1).
• First, the parser analyses the application specification and produces a new speci-
fication which integrates tailored transmission mechanisms.
4 T. Braun, I. Chrisment, C. Diot, F. Gagnon, L. Gautier, P. Hoschka
• Second, the ILP compiler, using the original data description written in C by the
application designer, and a description of data manipulation functions introduced
by the ALF compiler for transmission control purpose (i.e. checksum, encoding),
produces an efficient implementation organized in an ILP loop. A stub compiler
then produces a base frame for the communication over the network.
• Finally, a classic C compiler is used to link files produced by both the ALF and
the ILP compilers to the original user C procedures.
Application ADU specification EapSpTliEcRatEioLn ASopfptwlicaarteion
Designer in annotated C in C
specification
ESTEREL
ALF compiler protocol
specification
Protocol
NDU specification
Data
in annotated C
specification
Generated Software in annotated C
in C
ISC/ILP stub
compiler
include files +
interface routines in C
Protocol
Functions
C compiler
in C
Executable
Code
Figure 1. Structure of the ALFred Protocol Compiler
ALFred, an ALF/ILP Protocol Compiler for Distributed Application Automated Design. 5
We describe first our approach to high performance communication system architec-
ture. An application QoS (Quality of Service) is defined to allow the automated in-
tegration of transmission control modules to the application specification. This sec-
tion is also positioning our approach to the light of other related projects. Then we
explain (section 3) how to write application specifications. The application specifi-
cation is written with an annotated version of the ESTEREL language for the control
part and with C for the data description and the data manipulation functions.
Section 4 is dedicated to the ALF compiler which analyzes the application specifica-
tion to select and integrate the communication modules. Section 5 describes the ILP
compiler, from the ILP loop design to the INRIA Stub Compiler modification. Inte-
gration of ALF and ILP within the ALFred compiler, and also within a communica-
tion subsystem, will be described in section 6. Section 7 presents, both from a quan-
titative and a qualitative point of view, the performance of the protocol compiler. Au-
tomatons designed will be shown. Benchmarks will be done in both LAN and WAN
environments.
The report concludes with some discussion on our approach, and also on the perspec-
tives for the future evolution of ALFred.
6 T. Braun, I. Chrisment, C. Diot, F. Gagnon, L. Gautier, P. Hoschka
2 A New Communication System Architecture
2.1 Efficiency of high performance implementation techniques
The requirement for a new protocol architecture is clear. Traditional layered protocol
architectures such as the ISO OSI model and the ARPA Internet model are reaching
the very end of their lifetime.
The artificial separation of concerns in layers is partly due to the hardware architec-
ture of the70's. The service/protocol concept derives historically from the model that
presents interfaces between different service providers. There would be a link, net-
work, transport and session provider, perhaps all of which would have different po-
tential vendors. Even in a single vendor software implementation, one could accuse
the layered model (TCP/IP or OSI) of causing inefficiency. In fact, the operations of
multiplexing and segmentation both hide vital information that lower layers need to
optimize their performance. Although it is important to distinguish between the ar-
chitecture of a protocol suite and the implementation of a specific end system or a
relay node, the layered protocol architecture may unnecessarily reduce the engineer-
ing alternatives available to an implementor.
In fact, a certain degree of flexibility in the way functions are organized within the
layers is needed. A proposed solution is to integrate all transmission control layers in
a single block, in essence discarding the highly modular layered model in exchange
for performance.
2.1.1. ALF and ILP
In their SIGCOMM '90 paper [Clark90], Clark and Tennenhouse have proposed Ap-
plication Level Framing (ALF) as a key architectural principle for the design of a
new generation of protocols. ALF is in fact the natural result of advanced networking
experiments, which showed the need for ‘‘a rule of three units'' .
• A relatively old result is that efficient transmission can only be achieved if the
unit of control is exactly equal to the unit of transmission. Obvious penalties for
violating this rule are unnecessary large retransmissions in case of errors and inef-
ficient memory usage.
• The key idea expressed in [Clark90] is that the unit of transmission should also
be the unit of processing. Otherwise, large queues will build up in front of the re-
ceiving processes and eventually slow down the application.
• We found, through experience with multimedia services, that adaptive applica-
tions are much easier to develop if the unit of processing is also the unit of control.
According to the ALF principle, applications send their data in autonomous "frames''
(or Application Data Units (ADUs)) meaningful to the application. It is also desirable
that the presentation and transport layers preserve the frame boundaries as they pro-
ALFred, an ALF/ILP Protocol Compiler for Distributed Application Automated Design. 7
cess the data. In fact, this is in line with the widespread view that multiplexing of ap-
plication data streams should only be done once in the protocol suite. The sending
and receiving application should define what data goes in an ADU so that the ADUs
can be processed out of order. The ADU will be considered as the unit of "data ma-
nipulation'', which will simplify the processing. For example, an image server will
send messages corresponding to well identified parts of the picture. On the receiving
side, such frames can immediately be decompressed and the corresponding pixels
can be displayed on the screen, thus minimizing response times.
Integrated Layer Processing (ILP) is an engineering principle that has been suggested
for addressing the increased cost of data manipulation functions on modern worksta-
tions. In fact, the performance of workstations has increased with the advent of mod-
ern RISC architectures but not at the same pace as the network bandwidth during past
years. Furthermore, access to primary memory is relatively costly compared to cache
and registers, and the discrepancy between the processor and memory performance
is expected to get worse. The memory access is expected to represent a bottleneck
[Druschel93].
Protocol processing can be divided into two parts, control functions and data manip-
ulation functions. Example of data manipulation functions are presentation encod-
ing, checksuming, encryption and compression. In the control part there are func-
tions for header and connection state processing. [Clark89] has demonstrated that the
control part processing can match gigabit network performance for the most com-
mon size of PDUs with appropriate implementations.
Data manipulation functions present a bottleneck [Clark90][Gunningberg91]. They
consist of two or three phases. First a read phase where data is loaded from memory
to cache or registers, then a manipulation or "processing'' phase, followed by a write
phase for some functions, e.g., presentation encoding. For very "simple functions",
like checksuming or byte swap, the time to read and write to memory dominates the
processing time.
For other "processing oriented functions", like encryption and some presentation en-
coding, the manipulation time dominates with current processor speeds. However,
the situation is expected to change with the increase of processor performance: the
memory access will remain the major bottleneck rather than data processing.
The data manipulation functions are spread over different layers. In a classic protocol
suite implementation, the layers are mapped into distinct software or hardware enti-
ties which can be seen as atomic entities. The functions of each layer are carried out
completely before the protocol data unit is passed to the next layer. This means that
the optimization of each layer has to be done separately. Such ordering constraints
are in conflict with efficient implementation of data manipulation functions
[Wakeman92].
8 T. Braun, I. Chrisment, C. Diot, F. Gagnon, L. Gautier, P. Hoschka
The main concept behind ILP is to minimize costly memory read/write operations by
combining data manipulation oriented functions within one or two processing loops
instead of performing them serially as is most often done today. It is expected that
the cost reduction due to this optimization will result in better overall performance
as it will reduce time consuming memory access. This optimization may be applied
within a single data manipulation function (intra-function optimization) or across
several functions (inter-function optimization) [Dabbous94].
The interest of the ILP principle (and similar software pipelining principles such as
lazy message evaluation and delayed evaluation) has been discussed in [Clark90],
[Gunningberg91], [Partridge93b], [O’malley90], [Pehrson92] and [Abbott93a].
Previous work [Gunningberg91][Partridge93][Dabbous94] has demonstrated that
there is a performance benefit with ILP. The results show reduced processing time
for one PDU, as much as a factor of five when six simple data manipulation functions
were integrated. These reported results came from experiments that were isolated
from the rest of the protocol stacks and where hand-coded assembler routines were
used in order to control register allocation and cache behavior. Abbot and Peterson
[Abbott93b] use a language approach to integrate functions, but with less speedup.
In [Partridge93b] only two functions are integrated, data copying and checksum cal-
culation, but it is a real operational implementation of UDP. Experience with an im-
plementation of the XTP protocol [Dabbous93] showed improved performance
when ILP was used. This implementation is in user address space, which also dem-
onstrates that such implementations can perform as well as kernel tuned implemen-
tations. We should go one step further and integrate several of the data manipulation
functions in a complete, operational stack in order to understand the architectural im-
plications and the achievable speedup.
ALF and ILP were proposed in 1990 and for the time being there is no complete im-
plementation of a communication subsystem based on both concepts. Several rea-
sons make the design of a global framework for integrated implementation based on
ALF/ILP concepts now both feasible and attractive:
• The increase of processor speeds and of the discrepancy between processor and
memory performance is pushing toward the integration of data manipulation ope-
rations.
• Experience with an implementation of the XTP [Dabbous93] and TCP
[Braun95b][Castel94] protocols showed that user level software implementations
can perform as well as kernel tuned TCP, while still keeping the flexibility of con-
figurable software.
• Performance enhancements to the ASN.1 encoding facilitate the implementation
of a presentation filter [Dabbous92].
• Multiple communication services including group communication and variable
error control have been studied for a variety of applications (e.g. multimedia vi-