5. Complete Characterization of Proteic Extracts from Spirulina
5.3. Results and Discussion
5.3.6. Bioactive Properties of Aqueous Extracts
A traffic matrix M describes the average rate rij for a given time interval between the ingress nodes i and egress nodes j of a network.
M =
Traffic matrices form the input for network design and traffic engineering optimisation prob-lems. Therefore, it is important to determine traffic matrices in real networks. However,
measuring a traffic matrix is not a trivial task. [BR02] gives an overview over the two distinct approaches to measure a traffic matrix: The direct measurement approach as advocated by [FGL+00] uses e.g. NetFlow [Net04] to collect flow information. This information is eval-uated offline to derive the traffic matrix using the routing tables active at the measurement time that also have to be recorded. This approach is storage space and router-CPU intensive and requires all routers to support NetFlow (or a similar product) but contrary to other approaches allows to derive the point-to-multipoint traffic matrix. A point-to-point traffic matrix M models the traffic between ingress node i and egress j while the point-to-multipoint traffic matrix ˜M models the traffic and ingress node i and captures the fact that this traffic can exit at more than one egress j.
Another direct measurement approach that is less resource intensive is described by Schnitter and Horneffer [SH04]; it works for networks that employ label switching (MPLS).
Every LSP has a byte-counter measuring the traffic using this LSP. Thus, if a MPLS net-work is built as a full mesh of LSPs, the traffic matrix can be measured directly. However, due to scalability and load balancing reasons, a full mesh of LSPs is not often used. The technique introduced in [SH04] can measure the traffic matrix directly if the router has a byte-counter for each FEC2. It does not depend on the routing method (explicit LSPs with traffic engineering or plain shortest path routing).
Most of the other works favour deriving the traffic matrix from link measurements, as they are more readily available for all router interfaces via SNMP (simple network manage-ment protocol) in production networks. The problem with this approach is that estimating the traffic matrix is an ill-posed inverse linear problem: In a network with N ingress/egress nodes the traffic matrix size is O(N2) while there are only O(N ) link measurements – the problem becomes massively under-constrained for large N . To solve this problem, additional assumptions e.g. about the traffic and the routing have to be made. Approaches to this prob-lem can be classified into statistical tomographic methods, optimisation-based tomographic methods and other methods:
• Statistical tomographic methods use higher order statistics of the link load data like the covariance between two loads to create additional constraints. Examples are [Var96, TW98, CDWY00]. [Var96] and [TW98] assume a Poisson traffic model; [CDWY00]
assumes a Gaussian traffic model.
• Optimisation-based tomographic methods select a solution out of the solution space of the under-constrained problem that optimises a certain objective function using methods like linear or quadratic programming. [Gol00] is a simple example for this approach.
• Classified as other methods are approaches that combine the tomographic methods with other methods like gravity or choice models. [MTS+02] that use a logit choice model that captures the choices of users (where to download from) and network designers (how to interconnect the point of presences/POPs). The decision process is modelled as a utility maximisation problem.
[ZRDG03] combines a optimisation-based tomographic methods with a generalised grav-ity model. A gravgrav-ity model can for example be used to estimate the traffic between edge links by assuming that the traffic between i and j is proportional to the total traffic entering at i multiplied with the total traffic exiting at j.
2The exact requirements are that the statistics include each LSP through a router, incoming and outgoing labels, the FEC, the outgoing interface, and the byte counter. These requirements are fulfilled by the most common router operation systems like Cisco’s IOS and Juniper’s JUNOS [SH04].
[ZRLD03] uses an information theoretic approach that chooses the traffic matrix con-sistent with the measured data so that it is as close as possible to a model in which the source and destination pairs are independent and therefore the conditional probability p(j|i) that source i sends traffic to j is equal to the probability p(j) that the whole network sends traffic to j.
The rest of this part is structured as follows. In the next chapter the influence of traffic engineering on the QoS of a network and the costs respectively efficiency of that network are analysed. Traffic engineering strategies and performance metrics are discussed and then evaluated in a series of simulation experiments.
7.4 Outline
In Chapter 9 network engineering is discussed. The focus of that chapter lies on capacity expansion because providers have to expand the capacity of their network regularly – the Internet traffic has been growing exponentially in the last years [Odl03] and there is no indi-cation why this should not continue for the future. The capacity expansion problem therefore has to be solved much more often than the general design of a new network topology. Accord-ing to the system-oriented approach of this dissertation, we start by showAccord-ing how network engineering and the network architecture in the form of QoS systems interact. Then we present and evaluate different strategies for capacity expansion. After that, we investigate the interaction between traffic engineering and capacity expansion strategies in further ex-periments. Finally, we investigate the elasticity of traffic matrices resulting from the elastic behaviour of TCP and the impact on capacity expansion in an analytical study.
Evaluation of Traffic Engineering
Traffic Engineering is concerned with minimising over-utilisation of capacity when other ca-pacity is available in the network by rerouting traffic flows. A traffic flow in the context of this chapter is a macroflow consisting of all packets entering the network at the same ingress and exiting at the same egress node. The traffic flows of all ingress-egress node pairs are specified in the traffic matrix. Throughout this chapter, we assume that the traffic matrix is given. For MPLS networks, the traffic matrix can be measured online and exactly with the method described in [SH04]; for a general discussion of traffic matrix estimation techniques we refer to Section 7.3.
In this chapter, we investigate how traffic engineering influences the efficiency and the QoS of a network and explore the optimisation potential with an evaluation of different traffic engineering strategies.
We assume MPLS or an equivalent forwarding architecture (see Section 2.3) is used which allows to explicitly establish the path on which a flow is routed through the network. Different traffic engineering strategies that differ in their objective function, their constraints, and whether they can split up a macroflow to be routed along multiple paths (multipath routing) or not are investigated. Their performance with respect to different performance metrics is evaluated. In addition, the performance gain of the best traffic engineering strategies compared to a plain shortest path routing solution is evaluated. It measures the additional QoS achievable with traffic engineering and is a measure of the possible efficiency gain of traffic engineering.
As the currently dominant QoS architecture is an overprovisioned best-effort architec-ture; this architecture is assumed for the experiments in this work. Works evaluating traffic engineering in the context of other architectures, e.g. Diffserv, are discussed in Section 7.2.
For an evaluation of traffic engineering performance of a network for a given traffic matrix, the routing determined by the traffic engineering algorithm has to be measured. The routing in this context consists of the paths chosen for the different macroflows specified in traffic matrix. Therefore, we start by discussing different performance metrics for evaluating the routing. The average path length is an obvious performance metric. Besides it, several other performance metrics are possible, for example the bottleneck utilisation. They are discussed in Section 8.1. In Section 8.2, different strategies for solving the QoS maximising multicommodity flow problem are introduced; they are evaluated in a series of experiments in the rest of the chapter. The experiment setup is described in Section 8.3. After that, the experiment results are presented and discussed:
• In the first experiment (Section 8.4), we compare the path selection and explicit routing 145
formulation of the optimisation problem.
• A general performance evaluation of a large number of traffic engineering strategies is presented in Section 8.5. We start with a detailed evaluation of the strategies and all performance metrics in a basic experiment and then vary several parameters of the basic experiment – e.g. the used topology – to evaluate their influence.
• In Section 8.6, the performance loss of singlepath algorithms compared to multipath algorithms is evaluated.
• The most successful strategies need a number of precalculated paths. In Section 8.7, the influence of the precalculated paths on the performance of these strategies is evaluated.
Finally in Section 8.8, the conclusions are drawn and we give recommendations whether, and how to use traffic engineering.
8.1 Traffic Engineering Performance Metrics
For the evaluation of traffic engineering, the performance of how the traffic flows are routed through the network has to be evaluated. In this section, we discuss several metrics that can be used to evaluate the performance of the routing.
8.1.1 Path Length
Minimising the average path length between two nodes is an obvious and straightforward traffic engineering goal: With respect to different length metrics, minimising the path length is the objective of most standard interior routing protocols like OSPF (see Section 2.4.1).
The motivation behind the path length as performance metric is that the longer the path becomes, the more network resources are consumed and the higher the propagation delay becomes. As in a congested network the queueing delay can easily exceed the propagation delay of a hop, rerouting a flow so that it takes more hops through the network can still lead to improved overall delay besides a reduced loss probability. This observation is the basic motivation for doing traffic engineering instead of plain shortest path routing. Nevertheless, the path length remains an important performance metric for traffic engineering solutions.
8.1.2 Maximal respectively Bottleneck Utilisation
The utilisation ul of a link l is defined as the load ll per capacity (bandwidth) cl ul= ll
cl (8.1)
The utilisation of a link is an average over a certain period1, typical utilisation metrics measured in IP networks are based on 5 minute, 15 minute, 2 hour and 24 hour averages.
The maximum utilisation maxl{ul} describes how loaded the bottleneck link of the topol-ogy is. QoS parameters such as delay and loss are a (non-linear) function of the util-isation of a link. Because of the bursty nature of network traffic [PF95], losses occur
1On a very short timescale a link is either 100% utilised (data is currently being transmitted) or 0% (no data is currently being transmitted).
long before an average utilisation of 100% is reached. Minimising the maximum utilisa-tion therefore indirectly improves the QoS on the bottleneck link – the most critical link – and creates a zone of security against unpredicted traffic increases. Therefore, minimis-ing this metric is often the dominatminimis-ing traffic engineerminimis-ing goal in related works, see e.g.
[HS02a, HS02b, PdBdLVP+00, LW93, RTZ03].
One disadvantage of this metric is that it only focuses on the bottleneck link respectively bottleneck links, the other links are ignored.
8.1.3 Average Utilisation
Instead of evaluating the maximum utilisation – that is the utilisation of the bottleneck link – one could also evaluate the average utilisation of the network. This has the advantage that no link is ignored. However, a network with some highly loaded and some lightly loaded links could show the same average utilisation as a network with only medium loaded links. As the QoS a flow experiences – for example the loss probability – is largely determined by the most utilised link on its path and not by the average utilisation along its path this metric can be misleading. This is shown in some of the experiments below.
8.1.4 Average Load
The average utilisation metric does not take into account that there might be large differences in the capacity cl of the links in the topology. The average utilisation is influenced by low capacity links the same way as by high capacity links. High capacity links, however, typically carry more traffic flows and can therefore be expected to influence more flows respectively users than smaller links. If the utilisation metric is weighted with the link capacity, the average load is calculated.
This metric has the same disadvantages as the previous one. It is used in [PdBdLVP+00]
as secondary objective.
8.1.5 Congestion Costs
The high-level primary goal of traffic engineering should be to maximise the overall utility of the customers given the available network resources. This is a special form of the network efficiency as we used it throughout this thesis. The utility depends on the application, on the traffic mix and on network parameters like the loss or the queueing delay (see Chapter 4).
On the timescale of traffic engineering, it is the average of the network parameters like loss and delay that can be influenced. The network parameters are a non-linear function of the utilisation respectively load situation on a link. Assume for example a M/M/1/B queue [Kle75, Kle76]. The M/M/1/B queue is not the most realistic representation of an Internet link but is probably the most commonly used one because it can be mathematically handled very well. For more realistic queueing models see the queueing models of Appendix H. They, however, show a similar basic behaviour. For the M/M/1/B model with an average utilisation ρ that is given by the arrival rate λ and the service rate µ
ρ = λ
µ (8.2)
the loss probability p is
p = (1− ρ)ρB
1− ρB+1 (8.3)
and the queueing delay is proportional to the queue length l which is l = ρ
1− ρ −(B + 1)ρB+1
1− ρB+1 (8.4)
Loss and queue length are depicted in Figure 8.1. As one can see, the loss and delay are non-linear convex functions of the utilisation. In Section 9.1, we present a more detailed analysis based on the utility for various QoS systems using packet-level simulations instead of the M/M/1/B formulas. The results there also point out a convex relationship.
0
Figure 8.1: Loss and Queue Length of an M/M/1/B Queue with B = 20
The convex relationship between the utilisation and network congestion indicators like loss and delay has an important implication for traffic engineering. If the load of one highly utilised link is reduced by a certain amount due to a routing change, the overall performance can improve even if the load on multiple other (but not so highly utilised) links is increased because of the routing change. The lower the utilisation becomes, the less can be gained by rerouting.
This behaviour is not correctly expressed by any of the above-mentioned metrics. Therefore we propose to use the following metric called congestion costs2 that captures this non-linear behaviour. Figure 8.2 presents three different step-wise linear convex congestion cost functions px(u) that we use throughout this chapter to model how the congestion situation of a link depends on the utilisation of the link. [FT02] use a very similar metric to evaluate OSPF based traffic engineering. The parameters of the congestion cost functions are arbitrarily chosen but roughly oriented at Figure 8.1 and the results of Section 9.1. The default congestion cost function is labelled (1) and used in the following experiments by default if nothing else is mentioned, it is varied in Section 8.5.2.
The congestion costs are calculated for every link and can be summed up for the complete topology in the following two ways:
• Weighted congestion costs:
lll· px(ul)
The motivation behind weighting the congestion costs with the load llfollows the same argument as for the average load versus average utilisation metric above.
2The reason for calling this congestion measure “costs” becomes more visible in Chapter 9 where it has to be added to the costs for expanding the capacity of the network and therefore has to have the same unit as true monetary costs. For the experiments of this chapter, the scale and unit of this congestion measure do not matter and do not influence the results.
CongestionCosts
0.2 20
40 60 80 100
0.4 0.6 0.8 1.0
Utilisation (2)
(3) (1)
Figure 8.2: Congestion Functions
• Unweighted congestion level:
lpx(ul)
For comparison reasons we will also investigate the unweighted congestion costs metric in this chapter.