Request for Comments: 4128 AT&T Labs
Category: Informational June 2005
Bandwidth Constraints Models for
Differentiated Services (Diffserv)-aware MPLS Traffic Engineering:
Performance Evaluation
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
IESG Note
The content of this RFC has been considered by the IETF (specifically
in the TE-WG working group, which has no problem with publication as
an Informational RFC), and therefore it may resemble a current IETF
work in progress or a published IETF work. However, this document is
an individual submission and not a candidate for any level of
Internet Standard. The IETF disclaims any knowledge of the fitness
of this RFC for any purpose, and in particular notes that it has not
had complete IETF review for such things as security, congestion
control or inappropriate interaction with deployed protocols. The
RFC Editor has chosen to publish this document at its discretion.
Readers of this RFC should exercise caution in evaluating its value
for implementation and deployment. See RFC 3932 for more
information.
Abstract
"Differentiated Services (Diffserv)-aware MPLS Traffic Engineering
Requirements", RFC 3564, specifies the requirements and selection
criteria for Bandwidth Constraints Models. Two such models, the
Maximum Allocation and the Russian Dolls, are described therein.
This document complements RFC 3564 by presenting the results of a
performance evaluation of these two models under various operational
conditions: normal load, overload, preemption fully or partially
enabled, pure blocking, or complete sharing.
Table of Contents
1. Introduction ....................................................3
1.1. Conventions used in this document ..........................4
2. Bandwidth Constraints Models ....................................4
3. Performance Model ...............................................5
3.1. LSP Blocking and Preemption ................................6
3.2. Example Link Traffic Model .................................8
3.3. Performance under Normal Load ..............................9
4. Performance under Overload .....................................10
4.1. Bandwidth Sharing versus Isolation ........................10
4.2. Improving Class 2 Performance at the Expense of Class 3 ...12
4.3. Comparing Bandwidth Constraints of Different Models .......13
5. Performance under Partial Preemption ...........................15
5.1. Russian Dolls Model .......................................16
5.2. Maximum Allocation Model ..................................16
6. Performance under Pure Blocking ................................17
6.1. Russian Dolls Model .......................................17
6.2. Maximum Allocation Model ..................................18
7. Performance under Complete Sharing .............................19
8. Implications on Performance Criteria ...........................20
9. Conclusions ....................................................21
10. Security Considerations .......................................22
11. Acknowledgements ..............................................22
12. References ....................................................22
12.1. Normative References ....................................22
12.2. Informative References ..................................22
1. Introduction
Differentiated Services (Diffserv)-aware MPLS Traffic Engineering
(DS-TE) mechanisms operate on the basis of different Diffserv classes
of traffic to improve network performance. Requirements for DS-TE
and the associated protocol extensions are specified in references
[1] and [2] respectively.
To achieve per-class traffic engineering, rather than on an aggregate
basis across all classes, DS-TE enforces different Bandwidth
Constraints (BCs) on different classes. Reference [1] specifies the
requirements and selection criteria for Bandwidth Constraints Models
(BCMs) for the purpose of allocating bandwidth to individual classes.
This document presents a performance analysis for the two BCMs
described in [1]:
(1) Maximum Allocation Model (MAM) - the maximum allowable bandwidth
usage of each class, together with the aggregate usage across all
classes, are explicitly specified.
(2) Russian Dolls Model (RDM) - specification of maximum allowable
usage is done cumulatively by grouping successive priority
classes recursively.
The following criteria are also listed in [1] for investigating the
performance and trade-offs of different operational aspects of BCMs:
(1) addresses the scenarios in Section 2 of [1]
(2) works well under both normal and overload conditions
(3) applies equally when preemption is either enabled or disabled
(4) minimizes signaling load processing requirements
(5) maximizes efficient use of the network
(6) minimizes implementation and deployment complexity
The use of any given BCM has significant impacts on the capability of
a network to provide protection for different classes of traffic,
particularly under high load, so that performance objectives can be
met [3]. This document complements [1] by presenting the results of
a performance evaluation of the above two BCMs under various
operational conditions: normal load, overload, preemption fully or
partially enabled, pure blocking, or complete sharing. Thus, our
focus is only on the performance-oriented criteria and their
implications for a network implementation. In other words, we are
only concerned with criteria (2), (3), and (5); we will not address
criteria (1), (4), or (6).
Related documents in this area include [4], [5], [6], [7], and [8].
In the rest of this document, the following DS-TE acronyms are used:
BC Bandwidth Constraint
BCM Bandwidth Constraints Model
MAM Maximum Allocation Model
RDM Russian Dolls Model
There may be differences between the quality of service expressed and
obtained with Diffserv without DS-TE and with DS-TE. Because DS-TE
uses Constraint Based Routing, and because of the type of admission
control capabilities it adds to Diffserv, DS-TE has capabilities for
traffic that Diffserv does not. Diffserv does not indicate
preemption, by intent, whereas DS-TE describes multiple levels of
preemption for its Class-Types. Also, Diffserv does not support any
means of explicitly controlling overbooking, while DS-TE allows this.
When considering a complete quality of service environment, with
Diffserv routers and DS-TE, it is important to consider these
differences carefully.
1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
2. Bandwidth Constraints Models
To simplify our presentation, we use the informal name "class of
traffic" for the terms Class-Type and TE-Class, defined in [1]. We
assume that (1) there are only three classes of traffic, and that (2)
all label-switched paths (LSPs), regardless of class, require the
same amount of bandwidth. Furthermore, the focus is on the bandwidth
usage of an individual link with a given capacity; routing aspects of
LSP setup are not considered.
The concept of reserved bandwidth is also defined in [1] to account
for the possible use of overbooking. Rather than get into these
details, we assume that each LSP is allocated 1 unit of bandwidth on
a given link after establishment. This allows us to express link
bandwidth usage simply in terms of the number of simultaneously
established LSPs. Link capacity can then be used as the aggregate
constraint on bandwidth usage across all classes.
Suppose that the three classes of traffic assumed above for the
purposes of this document are denoted by class 1 (highest priority),
class 2, and class 3 (lowest priority). When preemption is enabled,
these are the preemption priorities. To define a generic class of
BCMs for the purpose of our analysis in accordance with the above
assumptions, let
Nmax = link capacity; i.e., the maximum number of simultaneously
established LSPs for all classes together
Nc = the number of simultaneously established class c LSPs,
for c = 1, 2, and 3, respectively.
For MAM, let
Bc = maximum number of simultaneously established class c LSPs.
Then, Bc is the Bandwidth Constraint for class c, and we have
Nc <= Bc <= Nmax, for c = 1, 2, and 3
N1 + N2 + N3 <= Nmax
B1 + B2 + B3 >= Nmax
For RDM, the BCs are specified as:
B1 = maximum number of simultaneously established class 1 LSPs
B2 = maximum number of simultaneously established LSPs for classes
1 and 2 together
B3 = maximum number of simultaneously established LSPs for classes
1, 2, and 3 together
Then, we have the following relationships:
N1 <= B1
N1 + N2 <= B2
N1 + N2 + N3 <= B3
B1 < B2 < B3 = Nmax
3. Performance Model
Reference [8] presents a 3-class Markov-chain performance model to
analyze a general class of BCMs. The BCMs that can be analyzed
include, besides MAM and RDM, BCMs with privately reserved bandwidth
that cannot be preempted by other classes.
The Markov-chain performance model in [8] assumes Poisson arrivals
for LSP requests with exponentially distributed lifetime. The
Poisson assumption for LSP requests is relevant since we are not
dealing with the arrivals of individual packets within an LSP. Also,
LSP lifetime may exhibit heavy-tail characteristics. This effect
should be accounted for when the performance of a particular BCM by
itself is evaluated. As the effect would be common for all BCMs, we
ignore it for simplicity in the comparative analysis of the relative
performance of different BCMs. In principle, a suitably chosen
hyperexponential distribution may be used to capture some aspects of
heavy tail. However, this will significantly increase the complexity
of the non-product-form preemption model in [8].
The model in [8] assumes the use of admission control to allocate
link bandwidth to LSPs of different classes in accordance with their
respective BCs. Thus, the model accepts as input the link capacity
and offered load from different classes. The blocking and preemption
probabilities for different classes under different BCs are generated
as output. Thus, from a service provider’s perspective, given the
desired level of blocking and preemption performance, the model can
be used iteratively to determine the corresponding set of BCs.
To understand the implications of using criteria (2), (3), and (5) in
the Introduction Section to select a BCM, we present some numerical
results of the analysis in [8]. This is intended to facilitate
discussion of the issues that can arise. The major performance
objective is to achieve a balance between the need for bandwidth
sharing (for increasing bandwidth efficiency) and the need for
bandwidth isolation (for protecting bandwidth access by different
classes).
3.1. LSP Blocking and Preemption
As described in Section 2, the three classes of traffic used as an
example are class 1 (highest priority), class 2, and class 3 (lowest
priority). Preemption may or may not be used, and we will examine
the performance of each scenario. When preemption is used, the
priorities are the preemption priorities. We consider cross-class
preemption only, with no within-class preemption. In other words,
preemption is enabled so that, when necessary, class 1 can preempt
class 3 or class 2 (in that order), and class 2 can preempt class 3.
Each class offers a load of traffic to the network that is expressed
in terms of the arrival rate of its LSP requests and the average
lifetime of an LSP. A unit of such a load is an erlang. (In
packet-based networks, traffic volume is usually measured by counting
the number of bytes and/or packets that are sent or received over an
interface during a measurement period. Here we are only concerned
with bandwidth allocation and usage at the LSP level. Therefore, as
a measure of resource utilization in a link-speed independent manner,
the erlang is an appropriate unit for our purpose [9].)
To prevent Diffserv QoS degradation at the packet level, the expected
number of established LSPs for a given class should be kept in line
with the average service rate that the Diffserv scheduler can provide
to that class. Because of the use of overbooking, the actual traffic
carried by a link may be higher than expected, and hence QoS
degradation may not be totally avoidable.
However, the use of admission control at the LSP level helps minimize
QoS degradation by enforcing the BCs established for the different
classes, according to the rules of the BCM adopted. That is, the BCs
are used to determine the number of LSPs that can be simultaneously
established for different classes under various operational
conditions. By controlling the number of LSPs admitted from
different classes, this in turn ensures that the amount of traffic
submitted to the Diffserv scheduler is compatible with the targeted
packet-level QoS objectives.
The performance of a BCM can therefore be measured by how well the
given BCM handles the offered traffic, under normal or overload
conditions, while maintaining packet-level service objectives. Thus,
assuming that the enforcement of Diffserv QoS objectives by admission
control is a given, the performance of a BCM can be expressed in
terms of LSP blocking and preemption probabilities.
Different BCMs have different strengths and weaknesses. Depending on
the BCs chosen for a given load, a BCM may perform well in one
operating region and poorly in another. Service providers are mainly
concerned with the utility of a BCM to meet their operational needs.
Regardless of which BCM is deployed, the foremost consideration is
that the BCM works well under the engineered load, such as the
ability to deliver service-level objectives for LSP blocking
probabilities. It is also expected that the BCM handles overload
"reasonably" well. Thus, for comparison, the common operating point
we choose for BCMs is that they meet specified performance objectives
in terms of blocking/preemption under given normal load. We then
observe how their performance varies under overload. More will be
said about this aspect later in Section 4.2.
3.2. Example Link Traffic Model
For example, consider a link with a capacity that allows a maximum of
15 LSPs from different classes to be established simultaneously. All
LSPs are assumed to have an average lifetime of 1 time unit. Suppose
that this link is being offered a load of
2.7 erlangs from class 1,
3.5 erlangs from class 2, and
3.5 erlangs from class 3.
We now consider a scenario wherein the blocking/preemption
performance objectives for the three classes are desired to be
comparable under normal conditions (other scenarios are covered in
later sections). To meet this service requirement under the above
given load, the BCs are selected as follows:
For MAM:
up to 6 simultaneous LSPs for class 1,
up to 7 simultaneous LSPs for class 2, and
up to 15 simultaneous LSPs for class 3.
For RDM:
up to 6 simultaneous LSPs for class 1 by itself,
up to 11 simultaneous LSPs for classes 1 and 2 together, and
up to 15 simultaneous LSPs for all three classes together.
Note that the driver is service requirement, independent of BCM. The
above BCs are not picked arbitrarily; they are chosen to meet
specific performance objectives in terms of blocking/preemption
(detailed in the next section).
An intuitive "explanation" for the above set of BCs may be as
follows. Class 1 BC is the same (6) for both models, as class 1 is
treated the same way under either model with preemption. However,
MAM and RDM operate in fundamentally different ways and give
different treatments to classes with lower preemption priorities. It
can be seen from Section 2 that although RDM imposes a strict
ordering of the different BCs (B1 < B2 < B3) and a hard boundary
(B3 = Nmax), MAM uses a soft boundary (B1+B2+B3 >= Nmax) with no
specific ordering. As will be explained in Section 4.3, this allows
RDM to have a higher degree of sharing among different classes. Such
a higher degree of coupling means that the numerical values of the
BCs can be relatively smaller than those for MAM, to meet given
performance requirements under normal load.
Thus, in the above example, the RDM BCs of (6, 11, 15) may be thought
of as roughly corresponding to the MAM BCs of (6, 6+7, 6+7+15). (The
intent here is just to point out that the design parameters for the
two BCMs need to be different, as they operate differently; strictly
speaking, the numerical correspondence is incorrect.) Of course,
both BCMs are bounded by the same aggregate constraint of the link
capacity (15).
The BCs chosen in the above example are not intended to be regarded
as typical values used by any service provider. They are used here
mainly for illustrative purposes. The method we used for analysis
can easily accommodate another set of parameter values as input.
3.3. Performance under Normal Load
In the example above, based on the BCs chosen, the blocking and
preemption probabilities for LSP setup requests under normal
conditions for the two BCMs are given in Table 1. Remember that the
BCs have been selected for this scenario to address the service
requirement to offer comparable blocking/preemption objectives for
the three classes.
Table 1. Blocking and preemption probabilities
BCM PB1 PB2 PB3 PP2 PP3 PB2+PP2 PB3+PP3
MAM 0.03692 0.03961 0.02384 0 0.02275 0.03961 0.04659
RDM 0.03692 0.02296 0.02402 0.01578 0.01611 0.03874 0.04013
In the above table, the following apply:
PB1 = blocking probability of class 1
PB2 = blocking probability of class 2
PB3 = blocking probability of class 3
PP2 = preemption probability of class 2
PP3 = preemption probability of class 3
PB2+PP2 = combined blocking/preemption probability of class 2
PB3+PP3 = combined blocking/preemption probability of class 3
First, we observe that, indeed, the values for (PB1, PB2+PP2,
PB3+PP3) are very similar one to another. This confirms that the
service requirement (of comparable blocking/preemption objectives for
the three classes) has been met for both BCMs.
Then, we observe that the (PB1, PB2+PP2, PB3+PP3) values for MAM are
very similar to the (PB1, PB2+PP2, PB3+PP3) values for RDM. This
indicates that, in this scenario, both BCMs offer very similar
performance under normal load.
From column 2 of Table 1, it can be seen that class 1 sees exactly
the same blocking under both BCMs. This should be obvious since both
allocate up to 6 simultaneous LSPs for use by class 1 only. Slightly
better results are obtained from RDM, as shown by the last two
columns in Table 1. This comes about because the cascaded bandwidth
separation in RDM effectively gives class 3 some form of protection
from being preempted by higher-priority classes.
Also, note that PP2 is zero in this particular case, simply because
the BCs for MAM happen to have been chosen in such a way that class 1
never has to preempt class 2 for any of the bandwidth that class 1
needs. (This is because class 1 can, in the worst case, get all the
bandwidth it needs simply by preempting class 3 alone.) In general,
this will not be the case.
It is interesting to compare these results with those for the case of
a single class. Based on the Erlang loss formula, a capacity of 15
servers can support an offered load of 10 erlangs with a blocking
probability of 0.0364969. Whereas the total load for the 3-class BCM
is less with 2.7 + 3.5 + 3.5 = 9.7 erlangs, the probabilities of
blocking/preemption are higher. Thus, there is some loss of
efficiency due to the link bandwidth being partitioned to accommodate
for different traffic classes, thereby resulting in less sharing.
This aspect will be examined in more detail later, in Section 7 on
Complete Sharing.
4. Performance under Overload
Overload occurs when the traffic on a system is greater than the
traffic capacity of the system. To investigate the performance under
overload conditions, the load of each class is varied separately.
Blocking and preemption probabilities are not shown separately for
each case; they are added together to yield a combined
blocking/preemption probability.
4.1. Bandwidth Sharing versus Isolation
Figures 1 and 2 show the relative performance when the load of each
class in the example of Section 3.2 is varied separately. The three
series of data in each of these figures are, respectively,
class 1 blocking probability ("Class 1 B"),
class 2 blocking/preemption probability ("Class 2 B+P"), and
class 3 blocking/preemption probability ("Class 3 B+P").
For each of these series, the first set of four points is for the
performance when class 1 load is increased from half of its normal
load to twice its normal. Similarly, the next and the last sets of
four points are when class 2 and class 3 loads are increased
correspondingly.
The following observations apply to both BCMs:
1. The performance of any class generally degrades as its load
increases.
2. The performance of class 1 is not affected by any changes
(increases or decreases) in either class 2 or class 3 traffic,
because class 1 can always preempt others.
3. Similarly, the performance of class 2 is not affected by any
changes in class 3 traffic.
4. Class 3 sees better (worse) than normal performance when either
class 1 or class 2 traffic is below (above) normal.
In contrast, the impact of the changes in class 1 traffic on class 2
performance is different for the two BCMs: It is negligible in MAM
and significant in RDM.
1. Although class 2 sees little improvement (no improvement in this
particular example) in performance when class 1 traffic is below
normal when MAM is used, it sees better than normal performance
under RDM.
2. Class 2 sees no degradation in performance when class 1 traffic is
above normal when MAM is used. In this example, with BCs 6 + 7 <
15, class 1 and class 2 traffic is effectively being served by
separate pools. Therefore, class 2 sees no preemption, and only
class 3 is being preempted whenever necessary. This fact is
confirmed by the Erlang loss formula: a load of 2.7 erlangs
offered to 6 servers sees a 0.03692 blocking, and a load of 3.5
erlangs offered to 7 servers sees a 0.03961 blocking. These
blocking probabilities are exactly the same as the corresponding
entries in Table 1: PB1 and PB2 for MAM.
3. This is not the case in RDM. Here, the probability for class 2 to
be preempted by class 1 is nonzero because of two effects. (1)
Through the cascaded bandwidth arrangement, class 3 is protected
somewhat from preemption. (2) Class 2 traffic is sharing a BC
with class 1. Consequently, class 2 suffers when class 1 traffic
increases.
Thus, it appears that although the cascaded bandwidth arrangement and
the resulting bandwidth sharing makes RDM work better under normal
conditions, such interaction makes it less effective to provide class
isolation under overload conditions.
4.2. Improving Class 2 Performance at the Expense of Class 3