NC-maude: a rewriting tool to play with network calculus

NC-maude: a rewriting tool to play with network calculus Marc Boyer ONERA – Toulouse, France [email protected] February 22, 2011 Abstract Embedded real-time systems are more and more distributed communicating systems. Then, to ensure correctness of application, respect of task dead-line must be ensured, but communication delays must also be bounded. Network calculus is a theory designed to compute such bounds (it have been successfully applied on A380 AFDX backbone). In order to disseminate, and to experiment new results, a tool is needed. Unlike other tools, its purposes are to be open, to allow the user to see the class of function manipulated (sub-additive, star-shaped, concave), the theorems used to get results, etc. To get a code as close as possible to the mathematical context, we chose to use a rewriting language, Maude.

1

Introduction

Networks introduce delays in communications between computers. When these computers run critical real-time applications, like in avionic systems, the delays introduced by the network must be bounded. The AFDX is the technology chosen by Airbus for its backbone. AFDX is an Ethernet based technology. AFDX have been chosen because it offers a large bandwidth (100Mb/s), allow connections of hundreds of computers, and is a mature technology. It uses full duplex links to avoid collisions and the indeterministic random backoff retransmission algorithm. Then, the only indeterminism comes from the delays in shared switch queues. Among other theories, network calculus (NC) was chosen to certify the AFDX backbone in Airbus A380 [Gri04]. Network calculus allows to compute upper bounds on network delays, assuming that one have constraints on the incoming flows (some traffic contract, expressed as an arrival curve), and guaranties on the service offered by the network elements (expressed as a service curve). From the first works on network calculus [Cru91a, Cru91b] to recent works [BT07, LMS04], with two reference books [LBT01, Cha00], and several exten1

sions [TCN00], network calculus is an active research area. Network calculus have a solid mathematical background: it is based on the (min,plus) algebra [BCGQ92]. Network calculus have been chosen for avionic embedded systems among other theories (based on scheduling theories) because it allows to handle very large systems (thousands of data flows), at the expense of pessimistic approximation on computed delay bounds. The need of an open tool arises because of several reasons: 1. a tool is needed because the size of the targeted systems excludes all handmade results, 2. such a tool must be open because the domain is very active, to allow each researcher to add its results to a “state of the art” code, 3. moreover, teaching and disseminating network calculus is facilitated by the existence of an open tool, which allow to play with different elements of the theory, not a complete configuration. Of course, there are already some tools, but they either are incomplete, or dedicated to specific extensions, or linked to no free tools. To begin, Section 2 presents network calculus. Section 3, refines this need of developing another tool. Section 4 presents the reasons of the choice of rewriting. Section 5 is an overview of NC-maude, the Maude code dedicated to computations in network calculus. Section 6 concludes. Appendix A describes a technical detail about tools DISCO and RTC.

2

Network calculus

Notations R is the set of real numbers, ∧ denotes the minimum operator, def and [x]+ = max(0, x). Here is a (very short) introduction to network calculus. The reader should refer to [Cha00, LBT01] for a complete presentation. Network calculus is a theory to get deterministic upper bounds in networks. It is mathematically based on the (∧, +) dioid (∧ denotes the minimum operator). Network calculus mainly handles non decreasing functions, null before 0: F . They are, among others, four common parametrised curves, δd , λR , βR,T , γr,b , defined by: δd (t) = 0 if t ≤ d, ∞ otherwise, λR (t) = Rt, βR,T (t) = R[t − T ]+ , and γr,b (t) = rt + b if t > 0, 0 otherwise. Three basic operators on F are of interest, convolution ∗, deconvolution &

2

γr,b βR,T

h(γr,b , βR,T )

t Figure 1: Common curves and delay and the sub-additive closure f ∗ . F = {f : R → R x < y =⇒ f (x) ≤ f (y), x < 0 =⇒ f (x) = 0} (1) (2) (f ∗ g)(t) = inf (f (t − u) + g(u)) 0≤u≤t

(f & g)(t) = sup(f (t + u) − g(u))

(3)

0≤u

f ∗ = δ0 ∧ f ∧ (f ∗ f ) ∧ (f ∗ f ∗ f ) ∧ · · ·

(4)

A flow is represented by its cumulative function R ∈ F , where R(t) is the total number a bits send by this flow up to time t. A flow R is said to have a function α ∈ F as arrival curve iff ∀t, s ≥ 0 : R(t + s) − R(t) ≤ α(s). It means that, from any instant t, the flow R will produce at most α(s) new data in s time units. An equivalent condition, expressed in the (∧, +) dioid is R ≤ R∗α. If α is an arrival curve for R, also is α∗ . A server has a service curve β iff for all arrival flow, the relation R# ≥ R ∗ β holds between the input flow R and the output flow R# . In this case, α# = α & β is an arrival curve for R# . The delay experimented by the flow R can be bounded by the maximal horizontal difference between curves α and β, formally defined by h(α, β) (a graphical interpretation of h can be found in Figure 1). h(α, β) = sup (inf {τ ≥ 0 α(s) ≤ β(s + τ )}) s≥0

These first results allow to handle linear topologies, like the one of Figure 2. Given the arrival curve α of flow R, and the services curves β, β # of network elements S, S # , we are able to compute a bound on the delay in S: h(α, β), and another for the delay in S # : h((α & β)∗ , β # ).

In case of more realistic topology, when a network element is shared by different flows, with some service policy (FIFO, static priority, etc.), it also exists results to compute bounds on each flow. For example, with the non preemptive static priority policy, it is known1 that the lower priority flow has 1 To be precise, there is a restriction on the flavor of service, which must be strict. See [LBT01, Def 1.3.2, Cor. 6.2.1,] for details.

3

R

S

R#

S#

R##

Figure 2: A flow going through two network elements in sequence R1#

R1

S#

S R2

R1##

R3

Figure 3: A topology with shared network elements the residual service βL = [β − αH ]+ , if the network element has service curve β and the high priority flow has arrival curve αH . Considering that the flow R1 of Figure 3 has the low priority, the delay in S can be bounded by h(α1 , [β − α2 ]+ ) and the delay in S # can be bounded by ∗ h((α1 & [β − α2 ]+ ) , [β # − α3 ]+ ). This little example shows the three main features of a network calculus tool: encoding the network (topology and characteristics), applying network calculus results, computing (∧, +) operations on curves. Lets us consider the last one, (∧, +) operations: these operators are mathematically defined, a lot of properties have been shown (distributivity, isotonicity...), but the effective computation is defined only on some specific classes (mainly piecewise linear functions, concave, convex, pseudo-periodic [BT07]), and the computation cost of each operator depends on the considered class. For example, if f, f # are concave functions, f ∗ f # = f ∧ f # , f ∗ = f . In the general case of piecewise linear pseudo-periodic, such computations are polynomials. The second one, applying network calculus results, is the main objective of the tool: the system must be open to allow users to apply different theorems on configurations, to see the effects of different modellings, and to add new results. Last feature, encoding the network, is just data representation.

3

WhAT: Why Another Tool ?

They are several tools already developed for network calculus. As presented in introduction, the size of the targeted systems (thousands of flows) prevents from any hand-made system analysis, and any researcher in the area must have some running code to experiment its results. But, each time, the same question arises: going from an existing tool or developing a new one. 4

One the one hand, developing a tool is a good way to get experience in a domain, but it could be very time consuming. On the other hand, extending an existing academic source could be harder than rewriting it from scratch2 ... But here, they are also others reasons.

3.1

DISCO

The DISCO network calculator [GZMS08, SZ06, DIS] is developed by the DISCO research group of technical university of Kaiserslautern (Germany). As presented in the web page, it is a network calculus library developed in Java, and “the core of this library is the class ”Curve” which represents piecewise-linear curves and provides min-plus-algebraic operations on these.” DISCO is as open as a Java code could be: it is mainly an API, which allow to create curves and topologies, and also to compute delays, using several analysis methods. The kind of curves manipulated is wide-sense increasing piece-wise linear functions, with a finite set of segments. This is a smaller class than the one described in [BT07] and implemented in [COI]. DISCO is made of around 5000 lines of Java code and 500 lines of comments.

3.2

COINC

COINC is the implementation of the algorithms presented in [BT07]. The aim of [BT07] was to find a manipulable (i.e. with algorithms) class of functions closed under the operators used in network calculus (sum, difference, minimum, maximum, convolution, deconvolution, and sub-additive closure). The piecewise linear functions, with a finite set of segments, seems a good candidate (this is the choice of [GZMS08]). But the sub-additive closure goes out of this class, and one need to consider the set of piece-wise finally pseudo-periodic functions (with rational values) to keep a class closed by all operators. In [BT07], the algorithms for all operators in this class are given, and their implementation is the aim of [COI]. COINC activity have been stuck a few years as an interpreter where sub-additive closure was not implemented. During year 2009, the implementation have been completed and the C++ code can be called from Scilab [Sci]. COINC is made of 4000 lines of C++ with about 1000 lines of comments, mostly in french.

3.3

CyNC

The Cyclic Network Calculus tool (CyNC, [Sch]) have been developed to illustrate the ability of network calculus to handle cyclic dependencies [SJDL05, SNLJ06]. The tool is a Matlab/Simulink library, which allow to graphically describe a system, and analyse it. 2 Especially

when the code uses break and continue instructions.

5

The project seems to be frozen (the last update on [Sch] is from July 2005). CyNC is made of 800 lines of Matlab code, with 26 lines of comments, without any explanation on the data model, which makes its reuse very hard.

3.4

RTC

The Real-Time Calculus Toolbox [WT06] is presented as a Matlab library, but it is more than that: it is a Java library with an API, and a Matlab interface. The kind of curve manipulated by RTC is the same than COINC: piecewise affine functions finally pseudo-periodic. Most operators are implemented, except sub-additive closure. The theory implemented in RTC is not the basic network calculus, but the Real-Time Calculus, an extension of the basic theory [TCN00], and a specific solution for cyclic dependencies MPA [TS09]. RTC is made of 4000 lines of Matlab code, and 3500 lines of comments. The Java code is not distributed, but the API is distributed under html format, generated by javadoc, and presents 22 classes.

3.5

DEBORAH

DEBORAH is devoted to the computation of bounds in networks with FIFO policy, rate-latency services and token-bucket arrival curves [BLMS10]. It implements the results of [LMS04, LMMS05, LMS07]. It computes upper bound on delay. This implies solving some piecewise-linear programming problems3 . It also computes lower bounds on the worst delay, considering specific behaviour. DEBORAH is made of 6000 lines of C++, and about 1500 comment lines. It is distributed under the GPL licence.

3.6

PEGASE

The french national project PEGASE is devoted to aerospace communication systems, including new results in network calculus and industrial transfer [PEG10, BNOT10]. In this context, the company RealTime-at-Work develops a network calculus tool [Rea]. It is decomposed in several blocs: one min-plus computing library, a network calculus core, and some professional features like a user friendly GUI, network editor, etc [BNOT10, § 6]. The min-plus part is a Java implementation of the results of [BT07], and is free for academic use. This module has the same objectives as COINC (see section 3.2) but has been re-developed for several reasons, including intellectual properties, implementation language, code maintenance, code validation, etc. To increase its confidence, it imports (and passes) the unitary tests of NCmaude. 3 The complexity is theoretically exponential, but some heuristics keep the computation time reasonable on real example.

6

3.7

NC-maude objectives

Once we have presented the other tools, what are the design challenges of a new one? The aim is to be more “open” for beginners: having a syntax close to the mathematics used in the papers, having an interpreter to allow to interactively manipulate the different elements, and manipulating (∧, +) and network calculus object in the same environment. The goal is not to have a black-box, with user-friendly GUI, taking a network topology as input and giving some bounds as output. Such tool is, of course, necessary to an industrial use, but is not NC-maude goal. Let make some comparisons with other tools. Compared to COINC, the goal was to consider a smaller class of functions, with simpler (and so more readable) implementation, but also to implement the network calculus results, not only the (∧, +) algebra. All of these tools handle coarsely the types of functions: they all works with piecewise linear functions, but information such as concavity are not in the type system, and the code is full of test like if (!isConvexe(...)). And such type information are useful in this context: for example, it is known that the convolution of two concave functions, both null at zero, is equal to the minimum of such functions (which is easier to compute). The NC-maude code handles very finely variety types of functions, widesense increasing, null at 0, star-shaped, concave, convexe, etc. DISCO implements network calculus results, but does not have any interpreter or interface. One must write Java code to define functions and net topologies. The DISCO and RTC tools made some approximations with the mathematical background, on continuity for example, which does not affect the quality of the results, but could be disturbing for beginners. In the RTC tutorial is written the following “The various functions of the RTC Toolbox will interpret a discontinuity correctly as either left- or right-continuous depending on the context of the curve.”. An example of such approximation is presented in appendix A. NC-maude tries to be strictly conform to the theory. At least, the relationships between RTC and NC are, up to now, unclear, and our goal was dissemination of NC. Its should also be free to help dissemination: any Matlab toolbox is linked to Matlab, which is an affordable tool for academics, but not really a free tool. A last difference with other tools: NC-maude uses rationals, not floating point numbers. It takes more computation time, but gives tractability to the results. The author of NC-maude is also involved in the PEGASE project, where the PEGASE tool is currently developed. It implies some common points between both project (the min-plus module is written in Java, but the network-calculus module should use some rewriting based language). But NC-maude is designed to be an academic open prototype, since PEGASE is designed to be an industrial tool, which can be used by networks engineers without any deep knowledge of

7

NC theory.

4

Why rewriting ?

Note: in this section, we are using the term “rule” as a generic term that describes a rewriting pattern on terms, without distinction between equations, rule, conditional or not, as made in some tools. Once the decision to write an open extensible tool was made, the choice of a language had to be done. We chose to use rewriting-based language for the following reasons. 1. The syntax of a rewriting based tool expresses very naturally mathematical equations, and since networks calculus have a very formal mathematical part, a rewriting based code have several benefits. Readability The code is very closed to the problem itself, sorts, rewriting rules, are very closed to the mathematical definitions and theorems, Tractability Each non-trivial rule can be labelled by the reference of the theorem is implements. The link between specification and the code is really easy to do. Confidence Since the kernel of a rewriting tool is just the application of individual rules, the confidence into the results comes from the tractability on each rule. Moreover, if necessary, the rewriting trace can be used as a proof, since it is often easier to certify a specific proof than a generic tool. 2. Rewriting tools come with efficient matching algorithms, dedicated to mathematical based properties (associativity, commutativity, etc.), and exonerate the programmer to recode it. Of course, when using a specific language, some questions arise about the difficulty to add its own new algorithms or the efficiency of the programs. Sections 5.3 discusses this point.

5

NC-maude

The aim of NC-maude [Boy] is to be an open, extensible tool, designed for dissemination of NC theory. To achieve this goal of dissemination, we want the interactions from the user with the tool to be very close to the theory. Like other tools, the user must be able to describe a topology and to ask for bounds on flows. But, unlike others, it uses a syntax really closed to the theoretical papers, it allows the user to ask to the tool if a given function is known as star-shaped, to know which theorem is used at some point, etc. NC-maude uses rational computation: it costs more CPU than simple floating point numbers, but tractability is easier. 8

1

5

10

15

20

25

boyer-laptop% maude startNC.maude \||||||||||||||||||/ --- Welcome to Maude --/||||||||||||||||||\ Maude 2.4 built: Nov 6 2008 17:14:50 Copyright 1997-2008 SRI International Fri Aug 21 13:29:56 2009 Maude>red (Gamma 5 2 ) + (Gamma 3 5 ) . reduce in START-NC : Gamma 3 5 + Gamma 5 2 . result Gamma: Gamma 8 7 . Maude> red Gamma 8 7 :: Concave . reduce in START-NC : Gamma 8 7 :: Concave . result Bool: true Maude> red h(Gamma 5 3, Beta 9 2 ) . reduce in START-NC : h(Gamma 5 3,Beta 9 2) . result PosRat: 7/3 Maude> parse flow("R",Gamma 5 3) . Flow: flow("R",Gamma 5 3) Maude> parse netElem("S",Beta 9 2) . NetworkElement: netElem("S",Beta 9 2) Maude> red delay( flow( "R" , Gamma 5 3 ) , netElem( "S" , Beta 9 2 ) ) . reduce in START-NC : delay(flow("R",Gamma 5 3),netElem("S",Beta 9 2)) . result PosRat: 7/3 Maude> red flow( "R" , Gamma 5 3 ) | netElem( "S" , Beta 9 2 ) . reduce in START-NC : flow("R",Gamma 5 3) | netElem("S",Beta 9 2) . result Flow: flow("R|S",Gamma 5 13 ) Figure 4: NC-maude interaction illustration

Graphical output is done by generating gnuplot command which must be copied/pasted by the user into gnuplot.

5.1

An example of interaction

An example could gives a quicker overview than general description. Then, here are some examples of interactions. Keep in mind than NC-maude is designed to be a tool to support discovering of NC. In this illustrative section, we are going to use some domain-specific objects, like common functions γr,b , βR,T , or operators (horizontal deviation h), presented in Section 2. The Figure 4 shows an interaction example, on the (∧, +) domain. First request, line 8, is the sum of terms γ5,2 + γ3,5 . The tool computes the result, and gives the type of the result. We can wonder if the result is concave. This is done by using the built-in operator :: of Maude (line 11). And the interpreter answers it is. A last request in the (∧, +) world is the computation 9

Figure 5: NC-maude module describing the simple architecture of Figure 2 of the horizontal deviation between two curves: h(γ4,5 , β10,2 ) (line 14). Notice that the syntax of the request is really closed to the mathematical syntax. The user could also notice that the delay result is given as a rational, not a floating point number. To describe a topology, some domain-specific operators have been defined. A flow can be described by its name and it arrival curve (line 17), and a server can be described by also its name and its service curve (line 19). We can then ask the tool to compute the delay experimented by the flow in the server (line 21), and also the output flow (denoted with the pipe operator, by analogy with Unix shell syntax – line 24). To describe a complete topology, it is easier to define constants (operators without argument in Maude) in a module. A simple example in given in Figure 5. It describes the architecture presented in Figure 2 where a flow R goes in sequence through two servers S and S # .

5.2

NC-maude code description

The NC-maude tool is decomposed into three main parts (could be named packages in another language). The first one is the representation of the (∧, +) algebra. It defines some sorts on the set F (see section 2) of functions (denoted naturally F in the Maude code), the common operators (sum, min, max...), some of they basic properties (distributivity), and some domain-specific operators (convolution and deconvolution). It also defines some common functions and they related equations. This is done in a syntax very closed to the domain, as illustrated in the following lines, extracted from the code. 1

5

10

sort F . op _ + _ : F F -> F [assoc com] . op _ /\ _ : F F -> F [assoc com] . vars f g h : F . eq [DistAddMin] : f + ( g /\ h ) = (f + g ) /\ ( f + h ) . op Gamma _ _ : Rat Rat -> F . ceq [MinGammaGamma] : (Gamma r b) /\ (Gamma r’ b’) = Gamma r b if r