Architecture of the ALFred Compiler

ALFred Documentation

The ALF approach used to build ALFred (presented in JSAC'98) results in an architecture where a single process made of the application and its end-to-end transmission control is implemented in the user space of the operating system. This application level process interfaces the network protocols over the in-kernel UDP/IP.

Basic principles

In ALFred each Application Data Unit type has its own requirements in terms of QoS. In other words we can associate quite completely different communication protocols to different data flows. For example in the JukeBox server, the commands "start" a clip or "abort" a clip have to be reliably transmitted whereas the audio clip is more concerned with real-time characteristics. We have decided in the present prototype of ALFred to have one automaton per ADU type and one automaton for the application. This is a first approximation towards a single synchronous automaton that could be entirely written in Esterel.

For the time being the application and its underlying protocols automata communicate via an asynchronous queue. This was done for efficiency purposes. Note that it will be quite simple to integrate the different modules in Esterel: instead of giving the received ADU to an application queue just use a synchronous signal in Esterel to send it to the application module. Then put all the modules in parallel, and modulus some renamings, you will have a single integrated automaton to handle the application and its communication sub-system. The main drawback here is that a synchonized method is needed to run the automaton shared between application and network events handlers. This could dramatically interfere with scheduling of packets in the network. But it should become clear soon, at the light of this current version of the compiler, how to implement this single automaton without altering the scheduling of transmissions.

Management of ADUs

In our framework the ADUs are represented by Esterel signals that convey values of type the associated ADU type (also declared in the same Esterel module). All the features of the transmission of ADUs are associated to their ADU type. Suppose you have defined a certain ADU type to handle specific data transmission. You have then two choices to packetize your data which are expressed in the way you are naming your ADUs (signal names).

  1. If you want to give the ADU a precise semantics and use the ADU name to identify that semantics. For example the ADU startproc could start some distant procedure and be declared in the type COMMAND. This way you can make complex structures that can be attached to the same type and hence transmitted on the same flow with the same characteristics.
    In this case the ADU type must own at least one signal which is named differently than the type.
  2. If you just want to handle byte arrays and do not need any structures, the ADU type entirely determines the ADU itself. For example the ADU AUDIO can be declared in the type AUDIO. ALFred will know then that he has to handle byte arrays of length given by the application. In that case the ADU type own only one signal which has exactly the same name than its type
In both case, the reception of an ADU is expressed in Esterel by an input signal, and the sending of an ADU is expressed by the emission of an output signal.

QoS associated with ADU types

Two sets of requirements can be specified for a given type of transmission.

A high-level set of parameters can be set up by every body, even non-specialists in protocols. We give in the following the current high-level parameters implemented in ALFred and their possible values:

  1. reliability: non reliable | partial reliable | reliable
  2. in sequence delivery: yes | no
  3. real-time: non real-time | delay sensitive | jitter sensitive | delay&jitter sensitive
  4. mode: unicast | diffusion | collection | multicast
All these parameters are self explained, except for the partial reliable value of the "reliability" parameter and the "real-time" parameter. The partial reliability is a trade off to provide error correction and remain TCP friendly (ie do not take too much of the bandwith). The real-time parameter makes the distinction between delay and jitter if we want to stress on the delay (like in an interactive video application) or to stress on the jitter (like in an audio server where we can afford a quite large playout buffer) or both (like in Distributed Interactive System applications).
You can also precise if these ADU will be "send only", "receive only" or both, to eventually avoid opening extra sockets.

Note that if you select reliable/in-sequence/non real-time/unicast the TCP protocol will be used and if you select non-reliable/out-of-sequence/non-real-time/unicast the UDP protocol will be used.

This first phase should roughly select the protocol mechanisms which seems the most appropriate for the transmission. Then in a second phase, the user can set more detailed parameters concerning more directly the relevant protocol mechanisms. For exemple, in the current version of ALFred you can set the following parameters (not all implemented yet):

  1. Flow Control Mechanism: window | rate-based
    if "window" is selected: if "rate-based" is selected:
  2. Error Control Mechanism: Automatic Repeat reQuest | Forward Error Correction | ARQ+FEC
These parameters are not exhaustive -the congestion control mechanism should be added- and could evolve to take into account all kind of protocol parameters. This involves a lot of parameters that could be brought up to the application surface: general parameters such as the choice of the achnowledgement scheme - Cumulative ACK | SACK | NACK - as well as quan titative parameters such as the initial sliding window size, the receiving window size, etc.

QoS conditions of the network

The application should in turn adapt to the current conditions of the network for more efficiency. In ALFred the protocols adapt differently to congestion event from the network according to the type of transmission they implement. The congestion event is generaly triggered by the loss parameter and might entail different reactions, for example:

  1. If the ARQ scheme is selected in unicast mode, a "slow start/congestion avoidance" kind of algorithm can be applied.
  2. If the FEC scheme is selected in multicast mode, at the sender we can consider the available data rate at the path bottleneck, ie maximum bandwith, to increase the amount of FEC remaining TCP friendly; and at the receiver we can adapt by subscribing/unsubscribing to some layers (RLC).
  3. We can also mix all of these previous techniques ...
Another important parameter is the Path Maximum Transmission Unit (PMTU), that can be used to gather ADUs till reaching the MTU when loose time constraints.

Note that use in ALFred the mechanism developed by Bengt Ahlgren (SICS) to probe the network for the following parameters:

Delphine Kaplan
Last modified: Mon Sep 21 11:05:31 MET DST 1998