RFC 4128

Bandwidth Constraints Models for Differentiated Services (Diffserv)-aware MPLS Traffic Engineering: Performance Evaluation

📅 published June 2005, from ietf

RFC 4128: Bandwidth Constraints Models for Differentiated Services (Diffserv)-aware MPLS Traffic Engineering: Performance Evaluation 🎀

Okay bestie, the title block says this is RFC 4128, written by W. Lai at AT&T Labs. It's filed as Informational and dated June 2005. The header doesn't list any RFCs it obsoletes or updates, so it isn't replacing or changing anything else 🫶

Network Working Group · Request for Comments: 4128 · Category: Informational · June 2005 ✨

Status of This Memo 📜

This memo gives info to the Internet community. It doesn't specify an Internet standard of any kind. Distribution of this memo is unlimited 💅

Copyright (C) The Internet Society (2005).

IESG Note 🙈

So the IETF looked at this one. The TE-WG working group had no problem with it being published as an Informational RFC, so it might look a lot like a current IETF work in progress or a published IETF work. BUT. This is an individual submission, not a candidate for any level of Internet Standard, and the IETF isn't vouching for whether it's fit for any purpose. It also hasn't gone through complete IETF review for things like security, congestion control, or weird interactions with protocols that are already deployed. The RFC Editor picked to publish it at their discretion.

Readers should be careful about how much they trust this when deciding whether to implement or deploy it. For more info, check out RFC 3932 🚨

Abstract ✨

Okay so, "Differentiated Services (Diffserv)-aware MPLS Traffic Engineering Requirements", which is RFC 3564, lays out the requirements and selection criteria for Bandwidth Constraints Models. It describes two of them, the Maximum Allocation model and the Russian Dolls model. This doc is the sequel that actually tests how those two models behave 🦋 It looks at them under normal load, overload, preemption fully or partially enabled, pure blocking, and complete sharing. Main character energy, honestly 👑

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 🧚

Okay so, Differentiated Services (Diffserv)-aware MPLS Traffic Engineering, or DS-TE for short, works by treating different Diffserv classes of traffic differently so the network performs better 💖 The requirements for DS-TE and its protocol extensions are in references [1] and [2], respectively.

To do per-class traffic engineering instead of treating everything as one big blob, DS-TE puts different Bandwidth Constraints (BCs) on different classes. Reference [1] is the one that lays out the requirements and selection criteria for Bandwidth Constraints Models (BCMs), which decide how bandwidth gets handed out to each class 🎀

This doc analyzes the two BCMs from [1]:

(1) Maximum Allocation Model (MAM) - the maximum bandwidth each class is allowed to use, plus the total usage across all classes, are both spelled out explicitly.

(2) Russian Dolls Model (RDM) - the maximum allowable usage is set cumulatively, by grouping successive priority classes recursively. Think nesting dolls 🪆

Reference [1] also lists these criteria for checking the performance and trade-offs of the different operational sides 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

So here's the deal 💅 The BCM you pick can seriously change how well a network protects different classes of traffic, especially under heavy load, which matters if you want to hit your performance goals [3]. This doc builds on [1] by reporting how the two BCMs above perform under normal load, overload, preemption fully or partially enabled, pure blocking, and complete sharing. We're only focused on the performance-oriented criteria and what they mean for a real network. Put simply, we only care about criteria (2), (3), and (5), and we're skipping criteria (1), (4), and (6) 🙈

Related docs in this area are [4], [5], [6], [7], and [8].

In the rest of this doc, these DS-TE acronyms show up:

      BC    Bandwidth Constraint
      BCM   Bandwidth Constraints Model
      MAM   Maximum Allocation Model
      RDM   Russian Dolls Model

Here's a fun bit 🌈 The quality of service you get from plain Diffserv can be different from what you get with DS-TE, and it's not the same thing. DS-TE uses Constraint Based Routing and adds admission control on top of Diffserv, so it can do things Diffserv can't. Diffserv doesn't signal preemption on purpose, but DS-TE has multiple preemption levels for its Class-Types. Diffserv also has no real way to control overbooking, while DS-TE does. So if you're building a full QoS setup with Diffserv routers and DS-TE together, these differences are a big deal to think through 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 keep things simple, we use the casual phrase "class of traffic" to mean Class-Type and TE-Class, which are defined in [1]. We make two assumptions: (1) there are only three classes of traffic, and (2) every label-switched path (LSP) needs the same amount of bandwidth, no matter its class. We also focus on how one link with a set capacity uses its bandwidth, and we don't look at routing during LSP setup 💜

The concept of reserved bandwidth is defined in [1] too, to account for overbooking. Instead of getting into those details, we say each LSP gets 1 unit of bandwidth on a given link once it's up. That lets us measure link usage as just the number of LSPs running at the same time. Link capacity then works as the total limit on bandwidth usage across all classes 🦋

So, the three classes from above are class 1 (highest priority), class 2, and class 3 (lowest priority). When preemption is enabled, those are also the preemption priorities. To set up a general class of BCMs for our analysis under these assumptions, here's what we use:

      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, we also define:

      Bc = maximum number of simultaneously established class c LSPs.

So Bc is the Bandwidth Constraint for class c, and these relationships hold:

      Nc <= Bc <= Nmax, for c = 1, 2, and 3
      N1 + N2 + N3 <= Nmax
      B1 + B2 + B3 >= Nmax

For RDM, the BCs are set like this:

      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

And for RDM, we get these 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 that can analyze a general class of BCMs. Besides MAM and RDM, the BCMs it can analyze include ones with privately reserved bandwidth that other classes can't preempt 🌸

The Markov-chain model in [8] assumes Poisson arrivals for LSP requests, with exponentially distributed lifetimes. The Poisson assumption makes sense here because we aren't looking at individual packets arriving within an LSP. LSP lifetimes can also have heavy-tail characteristics. That effect should be accounted for when you evaluate one BCM all by itself. Since it would hit every BCM the same way, we ignore it to keep the head-to-head comparison simple. In principle, a suitably chosen hyperexponential distribution could capture some aspects of the heavy tail, but that would make the non-product-form preemption model in [8] a lot more complicated 😭

The model in [8] assumes admission control is used to hand out link bandwidth to LSPs of each class according to their respective BCs. So it takes the link capacity and the offered load from each class as input, and it outputs the blocking and preemption probabilities for each class under each set of BCs. From a service provider's point of view, that means that once you know the blocking and preemption performance you want, you can run the model over and over to figure out the matching set of BCs 💖

To see what happens when you use criteria (2), (3), and (5) from the Introduction to pick a BCM, we show some numbers from the analysis in [8]. The goal is to make it easier to talk through the issues that can come up. The big performance objective is finding a balance between bandwidth sharing (which boosts bandwidth efficiency) and bandwidth isolation (which protects each class's bandwidth access) ✨

Yes, this trade-off is the whole vibe. Sharing gets you efficiency, isolation gets you protection, and you have to find the sweet spot between them 🫶

Okay that's part 1 done bestie, more coming up next! 🌈

3.1. LSP Blocking and Preemption

okay so, back in Section 2 we met our three classes: class 1 (highest priority 👑), class 2, and class 3 (lowest priority 🥲). Preemption may or may not be turned on, and we're gonna check how each scenario performs 💅. When preemption is in play, the priorities are the preemption priorities. We're only looking at cross-class preemption, no within-class preemption, so nobody is fighting with their own squad 🙅‍♀️. The vibe is: class 1 can preempt class 3 or class 2 (in that order), and class 2 can preempt class 3 ✨.

Each class throws a load at the network, and that load is described by how fast its LSP requests arrive and how long an LSP lives on average. One unit of that load is an erlang 🦋. (In packet-based networks, people usually measure traffic by counting the bytes and/or packets sent or received over an interface during a measurement period. We're not caring about that here, though. We only care about bandwidth allocation and usage at the LSP level. So, to measure resource use in a way that doesn't depend on link speed, the erlang is the right unit for our purposes [9] 🤓.)

To keep Diffserv QoS from degrading at the packet level, the expected number of established LSPs for a class should line up with the average service rate the Diffserv scheduler can give that class 🎀. Overbooking is a thing, so the traffic a link actually carries can end up higher than expected, and that means QoS degradation may not be totally avoidable 😭.

BUT admission control at the LSP level really helps keep QoS degradation down 🫶. It enforces the BCs set up for each class, following the rules of whichever BCM is in use. So the BCs decide how many LSPs can be established at the same time for each class, under different operating conditions. By controlling how many LSPs each class gets admitted, you make sure the traffic sent to the Diffserv scheduler matches the packet-level QoS goals you're aiming for 🌸.

So, how do you judge a BCM? You look at how well it handles the offered traffic, both under normal and overload conditions, while still hitting the packet-level service objectives 💯. Assuming Diffserv QoS is already enforced by admission control, the performance of a BCM can be stated in terms of LSP blocking and preemption probabilities 🧚.

Different BCMs have different strengths and weaknesses, which is so real 🙈. Depending on the BCs picked for a given load, a BCM can do great in one operating region and kinda flop in another. Service providers mostly care about how useful a BCM is for their operational needs 💼. No matter which BCM gets deployed, the biggest thing is that it works well under the engineered load, like actually delivering the service-level objectives for LSP blocking probabilities 🔥. It's also expected to handle overload "reasonably" well 🥹. So, for comparison, the shared starting point we use for BCMs is that they meet the specified performance objectives for blocking/preemption under a given normal load. Then we watch how they behave under overload. We'll say more about this later in Section 4.2 👀.

okay let's make it concrete 🍓. Imagine a link with enough capacity for a maximum of 15 LSPs from different classes to be established at once. Every LSP is assumed to have an average lifetime of 1 time unit. Say this link is getting this much load:

2.7 erlangs from class 1, 3.5 erlangs from class 2, and 3.5 erlangs from class 3.

Now we look at a scenario where the blocking/preemption performance objectives for all three classes should be comparable under normal conditions (we cover other scenarios in later sections 🦋). To meet this service requirement under the load above, the BCs are picked like this:

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 real driver here is the service requirement, not the BCM 💖. The BCs above weren't just random picks. They were chosen to hit specific blocking/preemption performance objectives (we go into that in the next section 🎀).

Here's an intuitive way to think about that set of BCs 🧠. Class 1's BC is the same (6) for both models, because class 1 gets treated the same way under either model with preemption. BUT MAM and RDM work in fundamentally different ways and treat the lower-preemption-priority classes differently 😤. Looking at Section 2, RDM sets up a strict ordering of the BCs (B1 < B2 < B3) plus a hard boundary (B3 = Nmax), while MAM uses a soft boundary (B1+B2+B3 >= Nmax) with no specific ordering 🫠. As we'll explain in Section 4.3, that lets RDM share more between classes. More coupling like that means the numerical values of the BCs can be smaller than the ones for MAM and still meet the same requirements under normal load 🌈.

So in this example, the RDM BCs of (6, 11, 15) can be thought of as roughly matching the MAM BCs of (6, 6+7, 6+7+15) ✨. (Just to be clear: the design parameters for the two BCMs need to be different because they operate differently. Strictly speaking, the numerical correspondence isn't correct 🙃.) Either way, both BCMs are bounded by the same overall constraint, the link capacity of 15 🔒.

The BCs in this example are not meant to be typical values any service provider would use. They're just for illustration 📚. The analysis method we used can easily take a different set of parameter values as input 💅.

3.3. Performance under Normal Load

so in the example above, based on the BCs we chose, the blocking and preemption probabilities for LSP setup requests under normal conditions for the two BCMs are in Table 1 🎀. Remember that these BCs were picked for this scenario to meet the service requirement of comparable blocking/preemption objectives across 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 table above, 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 up, the values for (PB1, PB2+PP2, PB3+PP3) are all super close to each other 🥰. That confirms the service requirement (comparable blocking/preemption objectives for all three classes) got met for both BCMs ✅.

Next, the (PB1, PB2+PP2, PB3+PP3) values for MAM are very similar to the ones for RDM 👯. So in this scenario, both BCMs deliver really similar performance under normal load 💜.

Looking at column 2 of Table 1, class 1 sees exactly the same blocking under both BCMs, and that's kinda obvious since both give class 1 up to 6 simultaneous LSPs and nothing else 🙄. RDM does a little better, which you can see in the last two columns of Table 1 🌟. That's because the cascaded bandwidth separation in RDM effectively gives class 3 some protection from being preempted by higher-priority classes 🛡️.

Also, PP2 is zero in this case, and the reason is pretty specific 🤔. The BCs for MAM just happen to be picked so that class 1 never has to preempt class 2 for any of the bandwidth it needs. (Class 1 can, in the worst case, get all the bandwidth it needs just by preempting class 3 alone.) In general, this won't be the case 🙅‍♀️.

It's also interesting to compare these results to a single-class setup 🧁. Using the Erlang loss formula, a capacity of 15 servers can support an offered load of 10 erlangs with a blocking probability of 0.0364969 🧮. The total load for the 3-class BCM is actually lower, at 2.7 + 3.5 + 3.5 = 9.7 erlangs, but its blocking/preemption probabilities are higher 😬. So there's some loss of efficiency because the link bandwidth gets partitioned to handle different traffic classes, which means less sharing 🍰. We'll dig into this more later, in Section 7 on Complete Sharing 🔍.

4. Performance under Overload

okay so overload happens when the traffic on a system is greater than the system's traffic capacity 🚨. To check how things hold up under overload, the load of each class gets varied separately 🎢. The blocking and preemption probabilities aren't shown separately for each case. They get added together into one combined blocking/preemption probability 💅✨.

4.1. Bandwidth Sharing versus Isolation 💅

okay so Figures 1 and 2 show how performance shifts when we wiggle the load of each class from the example in Section 3.2, one class at a time 🎀. There are three series in each figure: 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 series, the first set of four points is class 1 load going from half its normal load up to twice normal. The next set of four does the same for class 2, and the last set does it for class 3 🌸.

These are the vibes for both BCMs ✨:

  1. The performance of any class generally degrades as its load increases 📉.
  2. 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, 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 🫶.

BUT the impact of class 1 traffic on class 2 performance is totally different between the two BCMs 😭. It's negligible in MAM and significant in RDM 💀.

  1. Class 2 sees little improvement (no improvement in this particular example) when class 1 traffic is below normal under MAM, but under RDM it sees better than normal performance 🍓.
  2. Class 2 sees no degradation when class 1 traffic is above normal under MAM. In this example, with BCs 6 + 7 < 15, class 1 and class 2 traffic is effectively being served by separate pools 🧚. So class 2 never sees preemption, and only class 3 gets preempted whenever it's necessary 🙈. The Erlang loss formula confirms this too: 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 💜.

So yeah, even though the cascaded bandwidth arrangement and the resulting bandwidth sharing makes RDM work better under normal conditions, that same interaction makes it less effective at providing class isolation under overload conditions 🌈.

4.2. Improving Class 2 Performance at the Expense of Class 3 🎀

now we look at a scenario where the service requirement is to give class 2 better blocking/preemption performance than class 3, while keeping class 1 performance at the same level as before 💖. (The use of minimum deterministic guarantee for class 3 is handled in the next section, so hold that thought 🧚.) To actually hit the class 2 performance objective, the class 2 BC gets bumped up. For example, BCs (6, 9, 15) are used for MAM, and (6, 13, 15) for RDM 🍓.

For both BCMs, as shown in Figures 1bis and 2bis, class 1 performance stays exactly the same, but class 2 now gets better performance, and class 3 pays for it 😭. That's totally because class 2 is getting more bandwidth access than class 3 ✨. Under normal conditions, the two BCMs perform about the same in terms of blocking and preemption probabilities for LSP setup requests, as shown in Table 2 💅.

Table 2. Blocking and preemption probabilities

BCM      PB1      PB2      PB3      PP2      PP3    PB2+PP2  PB3+PP3

MAM    0.03692  0.00658  0.02733     0     0.02709  0.00658  0.05441
RDM    0.03692  0.00449  0.02759  0.00272  0.02436  0.00721  0.05195

Under overload, the observations from Section 4.1 about how the two BCMs generally behave still apply, as shown in Figures 1bis and 2bis 🔥.

Here are two FAQs about how BCMs operate, bestie 🫶.

(1) For a link capacity of 15, would a class 1 BC of 6 and a class 2 BC of 9 in MAM result in the possibility of a total lockout for class 3?

This will certainly be the case when 6 class 1 and 9 class 2 LSPs are being established at the same time 💀. That offered load (6 class 1 and 9 class 2 LSP requests) won't lock out class 3 with RDM having a BC of 13 for classes 1 and 2 combined, but it will get class 2 LSPs rejected 🙈. If class 2 traffic were considered more important than class 3 traffic, then RDM would perform really poorly compared to MAM with BCs of (6, 9, 15) 😭.

(2) Should MAM with BCs of (6, 7, 15) be used instead so as to make the performance of RDM look comparable?

The answer is that this scenario isn't very realistic when the offered load is assumed to be (2.7, 3.5, 3.5) for the three classes, as stated in Section 3.2 🌸. Treating an overload of (6, 9, x) as a normal operating condition clashes with engineering the BCs according to the bandwidth each class actually needs 🙅. It would be rare for a given class to need so much more than its engineered bandwidth level. But if it did, the expectation based on design and normal traffic fluctuations is that this class would quickly release unneeded bandwidth back toward its engineered level, freeing up bandwidth for other classes 🦋.

Service providers engineer their networks based on traffic projections to decide network configurations and needed capacity 📊. All BCMs should be designed to operate under realistic network conditions 🌈. For any BCM to work properly, the BC values must be based on the projected bandwidth needs of each class, as well as on the bandwidth allocation rules of the BCM itself 💜. This makes sure the BCM works as expected under the intended design conditions. In operation, though, the actual load may turn out to be different from the design, so assessing a BCM's performance under overload is essential to see how well it can cope with traffic surges or network failures ⭐. Following this view, the basis for comparing two BCMs is that they meet the same or similar performance requirements under normal conditions, and how well they withstand overload 👑.

In operational practice, load measurement and forecasting would be useful for calibrating and fine-tuning the BCs so traffic from different classes can be redistributed accordingly ✨. Dynamic adjustment of the Diffserv scheduler could also be used to minimize QoS degradation 🫶.

4.3. Comparing Bandwidth Constraints of Different Models 🧚

as pointed out in Section 3.2, the higher degree of sharing among classes in RDM means its BC numerical values could be relatively smaller than those for MAM 💅. We're going to dig into this more with the following scenario 🔍. We set the BCs so that (1) both BCMs use the same value for class 1, (2) both BCMs offer the same minimum deterministic guarantee of bandwidth for class 3, and (3) the blocking/preemption probability is minimized for class 2 🎀. Real talk, this might not be how service providers actually pick BCs 🙈. It's done here just to investigate the statistical behavior of this deterministic mechanism 🧪.

For illustration, we use BCs (6, 7, 15) for MAM, and (6, 13, 15) for RDM 🍓. In this case, both BCMs have 13 units of bandwidth for classes 1 and 2 together, and dedicate 2 units of bandwidth for class 3 only 💖. The performance of the two BCMs under normal conditions is in Table 3. MAM with (6, 7, 15) gives fairly comparable performance objectives across the three classes, whereas RDM with (6, 13, 15) strongly favors class 2 at the expense of class 3 😭. So they cater to different service requirements ✨.

Table 3. 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.00449  0.02759  0.00272  0.02436  0.00721  0.05195

By comparing Figures 1 and 2bis, you can see that when the same set of BCs is used, RDM gives class 2 much better performance than MAM, with class 3 only slightly worse 🌈.

This backs up the Section 3.2 observation that, to meet the same service requirements under normal conditions, the BC numerical values for RDM can be relatively smaller than those for MAM 🦋. Honestly, that shouldn't be surprising, given the hard boundary (B3 = Nmax) in RDM versus the soft boundary (B1+B2+B3 >= Nmax) in MAM 💜. The strict ordering of BCs (B1 < B2 < B3) gives RDM the advantage of a higher degree of sharing among the classes, meaning it can reallocate the unused bandwidth of higher-priority classes to lower-priority ones, if needed ⭐. So RDM performs better when an identical set of BCs is used, like in the example above 👑. A higher degree of sharing like this may necessitate using a minimum deterministic bandwidth guarantee to protect lower-priority traffic from preemption 🫶.

MAM doesn't have an explicit ordering of BCs, and its boundary is soft. That means minimum deterministic guarantees for lower-priority classes may not need to be enforced when there's less sharing ✨. The example in Section 4.2 with BCs (6, 9, 15) for MAM shows this 🧚.

For illustration, Table 4 shows the performance under normal conditions of RDM with BCs (6, 15, 15) 🎀.

Table 4. Blocking and preemption probabilities

BCM      PB1      PB2      PB3      PP2      PP3    PB2+PP2  PB3+PP3

RDM    0.03692  0.00060  0.02800  0.00032  0.02740  0.00092  0.05540

Whether or not deterministic guarantees are used, both BCMs are bounded by the same aggregate constraint of the link capacity 🔥. Also, in both BCMs, bandwidth access guarantees are necessarily achieved statistically because of traffic fluctuations, as explained in Section 4.2 📊. (As a result, service-level objectives are typically specified as monthly averages, using statistical guarantees rather than deterministic ones 🌸.) So given the fundamentally different operating principles of the two BCMs (ordering, hard versus soft boundary), the dimensions of one BCM should not be adopted to design for the other 🙅. Instead, it's the service requirements, and perhaps also the operational needs, of a service provider that should drive how the BCs of a BCM are selected 💖.

5. Performance under Partial Preemption ✨

okay so in the last two sections, preemption was fully on 🔥. class 1 can preempt class 3 or class 2 (in that order), and class 2 can preempt class 3. that means classes 1 and 2 are both preemptor-enabled, while classes 2 and 3 are preemptable. a preemptor-enabled class can preempt lower-priority classes that are marked preemptable. a class that is not marked preemptable can't be preempted by any other class, no matter what the priorities are 🛡️

now we check out the three cases in Table 5, where preemption is only partially on 💅

   Table 5.  Partial preemption modes

   preemption modes         preemptor-enabled     preemptable

   "1+2 on 3" (Fig. 3, 6)   class 1, class 2        class 3
   "1 on 3"   (Fig. 4, 7)       class 1             class 3
   "1 on 2+3" (Fig. 5, 8)       class 1         class 3, class 2

in this section we look at how these preemption modes change the performance of one particular BCM. so we're basically comparing a BCM with preemption fully enabled against the same BCM with preemption partially enabled 👀 the RDM results are in Figures 3 to 5, and the MAM results are in Figures 6 through 8, respectively. in all of these figures, we use the BCs from Section 3.2 for illustration, i.e., (6, 7, 15) for MAM and (6, 11, 15) for RDM. the general behavior is similar when the BCs are changed to the ones in Sections 4.2 and 4.3, i.e., (6, 9, 15) and (6, 13, 15), respectively 🌸

5.1. Russian Dolls Model

let's look at RDM first 🪆 there are two sets of results, depending on whether class 2 is preemptable. (1) Figures 3 and 4 cover the two modes where only class 3 is preemptable, and (2) Figure 2 from the previous section and Figure 5 cover the two modes where both classes 2 and 3 are preemptable. comparing these two sets, here's what we can see when class 2 is non-preemptable:

  1. class 1 generally sees a higher blocking probability 😬 the class 1 space allocated by the class 1 BC is shared with class 2, and class 2 is now non-preemptable. so class 1 can't reclaim any of that space when it needs it. class 1 also has fewer chances to preempt, since it can only preempt class 3.
  2. class 3 sees higher blocking/preemption when its own load goes up too 📉 it gets preempted more often by class 1, since class 1 can't preempt class 2 anymore. (check the last set of four points for class 3 in Figures 3 and 4, and compare them with Figures 2 and 5.)
  3. class 2 sees less blocking/preemption even when its own load goes up 🙌 nobody is preempting it with class 1. (check the middle set of four points for class 2 in Figures 3 and 4, and compare them with Figures 2 and 5.)

there are also two more sets of results about whether class 2 is preemptor-enabled. when class 2 is not preemptor-enabled, class 2 blocking/preemption goes up as class 3 load goes up 😭 (check the last set of four points for class 2 in Figures 4 and 5, and compare them with Figures 2 and 3.) the reason is that classes 2 and 3 are now competing with each other for resources, full stop.

5.2. Maximum Allocation Model

now for MAM 🎀 the big impact shows up only on class 2, when it can't preempt class 3. that makes its blocking/preemption go up in two situations:

  1. when class 1 load goes up. (check the first set of four points for class 2 in Figures 7 and 8, and compare them with Figures 1 and 6.)
  2. when class 3 load goes up. (check the last set of four points for class 2 in Figures 7 and 8, and compare them with Figures 1 and 6.) this is similar to RDM, i.e., classes 2 and 3 are now competing with each other 🥊

if you compare Figure 1 (fully enabled preemption) with Figures 6 through 8 (partially enabled preemption), MAM is honestly pretty unbothered by the different preemption modes 😌 that's because when each class has its own bandwidth access limits, there's less interference between the classes. RDM, on the other hand, depends much more on which preemption mode is in use, so it's giving a very different energy 🎢

6. Performance under Pure Blocking 🚫

this section is about the case where preemption is completely disabled 🙅‍♀️ we keep using the numerical example from the previous sections, with the same link capacity and offered load.

6.1. Russian Dolls Model

for RDM, we consider two different settings:

"Russian Dolls (1)" BCs:

  • 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.

"Russian Dolls (2)" BCs:

  • up to 9 simultaneous LSPs for class 3 by itself,
  • up to 14 simultaneous LSPs for classes 3 and 2 together, and
  • up to 15 simultaneous LSPs for all three classes together.

the "Russian Dolls (1)" set is the same as before, with preemption enabled 🔁 but "Russian Dolls (2)" has the cascade of bandwidth arranged in reverse order of the classes, which is kind of iconic 🙃

as we saw in Section 4, the cascaded bandwidth arrangement is meant to give lower-priority traffic some protection from preemption by higher-priority traffic 🛡️ that's how we avoid starvation. in a pure blocking environment, that protection isn't needed anymore 🤷‍♀️ in fact, as Figure 9 shows, it does the opposite and creates an undesirable effect: higher-priority traffic sees higher blocking than lower-priority traffic 💀 without preemption, the higher-priority traffic should be protected instead, so it can get through when the load is high. and sure enough, when the reverse cascade is used in "Russian Dolls (2)", the performance goal of lower blocking for higher-priority traffic is hit, as Figure 10 shows 🎯 in this specific example, the three classes barely differ in the first eight data points of each of the three series. but the BCs can be tuned to get a bigger differentiation ✨

6.2. Maximum Allocation Model

for MAM, we also consider two different settings 💜

"Exp. Max. Alloc. (1)" BCs:

  • up to 7 simultaneous LSPs for class 1,
  • up to 8 simultaneous LSPs for class 2, and
  • up to 8 simultaneous LSPs for class 3.

"Exp. Max. Alloc. (2)" BCs:

  • up to 7 simultaneous LSPs for class 1, with additional bandwidth for 1 LSP privately reserved
  • up to 8 simultaneous LSPs for class 2, and
  • up to 8 simultaneous LSPs for class 3.

these BCs are picked so that, under normal conditions, the blocking performance looks similar to all the previous scenarios 🧁 the only difference between the two sets is that the "Exp. Max. Alloc. (2)" algorithm gives class 1 a private pool of 1 server for class protection. because of that, class 1 has relatively lower blocking, especially when its traffic is above normal (compare Figures 11 and 12). of course, this comes with a slight increase in the blocking of class 2 and class 3 traffic 🥲

when you compare "Russian Dolls (2)" in Figure 10 with MAM in Figures 11 or 12, the difference in behavior and the explanation behind it are again similar to the case where preemption is used. the higher degree of sharing in RDM's cascaded bandwidth arrangement creates tighter coupling between the classes under overload. so their performance tends to degrade together when the load of any one class goes up 🫠 MAM gives each class its own explicit maximum bandwidth usage, which gets you better class isolation 🧱 the trade-off is that blocking performance in MAM is generally somewhat higher than in RDM, because there's less sharing.

the difference in RDM's behavior with and without preemption was already covered at the start of this section. for MAM, comparing Figures 1 and 11 shows some other notable differences 👑 if preemption is used, higher-priority traffic tends to keep its performance even when other classes are overloaded. that's not the case when preemption isn't allowed. the trade-off is that the overloaded class generally sees relatively higher blocking/preemption when preemption is enabled than it would if preemption were disabled.

7. Performance under Complete Sharing 🌈

as we noticed near the end of Section 3, splitting up bandwidth capacity for access by different traffic classes tends to reduce the maximum link efficiency you can get 📉 now we look at the case with no such partitioning, which means all the classes fully share the total bandwidth. this is called the Complete Sharing Model 🤝

for MAM, this means the BCs allow up to 15 simultaneous LSPs for any class.

for RDM, the BCs are similar:

  • up to 15 simultaneous LSPs for class 1 by itself,
  • up to 15 simultaneous LSPs for classes 1 and 2 together, and
  • up to 15 simultaneous LSPs for all three classes together.

at this point, there's effectively no difference between MAM and RDM 🫶 Figure 13 shows the performance when all classes have equal access to link bandwidth under Complete Sharing.

with preemption fully enabled, class 1 sees virtually no blocking, no matter the loading conditions on the link 👑 class 2 can only preempt class 3, so class 2 sees some blocking and/or preemption when either class 1 load or its own load is above normal. otherwise, class 2 isn't affected by increases in class 3 load. since higher-priority classes always preempt class 3 when the link is full, class 3 takes the biggest hit, with high blocking/preemption whenever any class's load goes up 😭 comparing Figures 1, 2, and 13 shows that classes 1 and 2 do way better under Complete Sharing, but class 3 is much better off under either MAM or RDM 🥺 in a sense, class 3 gets starved under overload, because Complete Sharing gives its traffic no protection at all 💔

8. Implications on Performance Criteria ✨

okay so this is where everything comes together 🫶 the big theme keeps coming back to the trade-off between bandwidth sharing and class protection/isolation. to make it concrete, we compare the different BCMs by their overall loss probability. that's the long-term proportion of LSP requests from all classes combined that get lost to either blocking or preemption, for a given level of offered load 📊

as we saw in the earlier sections, RDM shares way more than MAM, but both of them end up converging to the Complete Sharing Model as their sharing degree keeps getting cranked up 🌈 Figure 14 shows that, for a single link, the overall loss probability is the smallest under Complete Sharing and the largest under MAM, with RDM landing right in the middle. put another way, Complete Sharing gives the highest link efficiency and MAM gives the lowest 📉

here's the wild part: the overall loss probability of Complete Sharing is identical to the loss probability of a single class as computed by the Erlang loss formula 🤯 but Complete Sharing has the poorest class protection capability. so it's efficient but kinda chaotic for the lower classes 💀 (Note that, in a network with many links and multiple-link routing paths, analysis in [6] showed that Complete Sharing does not necessarily lead to maximum network-wide bandwidth efficiency. 🧐)

more sharing helps link efficiency, ngl, but it also means the classes get more tightly coupled to each other 🧵 under normal loading, proper dimensioning of the link so that each class has adequate capacity can minimize that coupling 🎀 under overload, though, when capacity is scarce, the coupling is unavoidable and can cause severe degradation of service to the lower-priority classes 😭 so the objective of maximizing link usage from criterion (5) of Section 1 has to be handled with care, with due consideration for the interactions among the different classes. otherwise, using that criterion alone will lead you straight to the Complete Sharing Model, as shown in Figure 14 🙈

criterion (2) is about how well a BCM helps the network actually hit the expected performance. we can express that in terms of the blocking and/or preemption behavior each class sees under different loading conditions 🦋 for example, one way to show how strong a BCM is: count how many times worse the per-class blocking or preemption probability gets under overload compared to normal load 🔥

9. Conclusions 👑

okay the wrap-up! BCMs are used in DS-TE for path computation and admission control of LSPs. they enforce different BCs for different classes of traffic so that Diffserv QoS performance can be maximized 💖 so it makes sense to measure a BCM's performance by its LSP blocking/preemption probabilities under various operational conditions 📏 based on that, we analyzed and compared RDM and MAM for LSP establishment. we looked at three scenarios: (1) all three classes have comparable performance objectives in terms of LSP blocking/preemption under normal conditions, (2) class 2 gets better performance at the expense of class 3, and (3) class 3 receives some minimum deterministic guarantee ✨

the main theme, once again, is the trade-off: sharing bandwidth for greater efficiency under normal conditions, versus robust class protection/isolation under overload 🫧 here's the vibe check on the two BCMs:

RDM

  • allows greater sharing of bandwidth among different classes 🤝
  • performs somewhat better under normal conditions 🌸
  • works well when preemption is fully enabled; under partial preemption, not all preemption modes work equally well 🎢

MAM

  • does not depend on the use of preemption 🙌
  • is relatively insensitive to the different preemption modes when preemption is used 🧘‍♀️
  • provides more robust class isolation under overload 🛡️

and the last bit: preemption gives higher-priority traffic some degree of immunity to the overloading of other classes 🧚 which means the overloaded class ends up with higher blocking/preemption than it would in a pure blocking environment. not fair to the overloaded class, but that's the tradeoff, bestie 💅

10. Security Considerations 🔐

this document doesn't introduce any additional security threats beyond the ones described for Diffserv [10] and MPLS Traffic Engineering [11, 12, 13, 14]. the same security measures and procedures described in those documents apply here too 🫡 for example, the approach for defending against theft- and denial-of-service attacks discussed in [10] is to combine traffic conditioning at Diffserv boundary nodes with security and integrity of the network infrastructure within a Diffserv domain. that same combo may be followed when DS-TE is in use 🏰

also, as [11] states, it's really important that manipulation of administratively configurable parameters (like the ones related to DS-TE LSPs) be done in a secure manner by authorized entities 🔒 for example, preemption is an administratively configurable parameter, so it's critical that its values get set properly throughout the network 🚨 any misconfiguration in any label switch may cause new LSP setup requests to either be blocked or to unnecessarily preempt LSPs that are already established 😱 and the preemption values of LSP setup requests must be configured properly too, because otherwise they may affect the operation of existing LSPs. this section is not joking around, so please take it seriously 💀

11. Acknowledgements 🫶

big thanks to Jerry Ash, Jim Boyle, Anna Charny, Sanjaya Choudhury, Dimitry Haskin, Francois Le Faucheur, Vishal Sharma, and Jing Shen 🙏 their inputs are very much appreciated 🌷

12. References 📚

12.1. Normative References

  • [1] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.

12.2. Informative References

  • [2] Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005.
  • [3] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., Christian, B., and W. Lai, "Applicability Statement for Traffic Engineering with MPLS", RFC 3346, August 2002.
  • [4] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4125, June 2005.
  • [5] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4127, June 2005.
  • [6] Ash, J., "Max Allocation with Reservation Bandwidth Constraint Model for MPLS/DiffServ TE & Performance Comparisons", RFC 4126, June 2005.
  • [7] F. Le Faucheur, "Considerations on Bandwidth Constraints Models for DS-TE", Work in Progress.
  • [8] W.S. Lai, "Traffic Engineering for MPLS," Internet Performance and Control of Network Systems III Conference, SPIE Proceedings Vol. 4865, Boston, Massachusetts, USA, 30-31 July 2002, pp. 256-267.
  • [9] W.S. Lai, "Traffic Measurement for Dimensioning and Control of IP Networks," Internet Performance and Control of Network Systems II Conference, SPIE Proceedings Vol. 4523, Denver, Colorado, USA, 21-22 August 2001, pp. 359-367.
  • [10] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
  • [11] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
  • [12] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
  • [13] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
  • [14] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.

Author's Address 📮

Wai Sum Lai AT&T Labs Room D5-3D18 200 Laurel Avenue Middletown, NJ 07748 USA

Phone: +1 732-420-3712 EMail: wlai@att.com

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🧾

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 💖

Funding for the RFC Editor function is currently provided by the Internet Society. 🌈

📦 where this page comes from