Traffic Engineering Working Group Wai Sum Lai Internet Draft AT&T Document: draft-wlai-tewg-bcmodel-00.txt June 2002 Expires: December 2002 Bandwidth Constraint Models for Diffserv-aware MPLS Traffic Engineering Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document is available in both .txt and .pdf formats. Abstract This document is intended to complement the Diffserv-aware MPLS TE Requirements document by describing the implications of some of the criteria for selecting a default bandwidth constraint model. Properties of candidate models are also presented to provide guidance to the corresponding Solution document for this selection. Contributions are welcome. Please send comments to the mailing list te-wg@ops.ietf.org Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and Lai Expires - December 2002 [Page 1] BC Models for Diffserv-aware MPLS TE June 2002 "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Table of Contents 1. Introduction..................................................2 2. Performance Under Normal Load.................................3 3. Performance Under OverLoad....................................5 4. Performance Under Complete Sharing............................6 5. Implications on Selection Criteria............................7 Security Considerations..........................................8 References.......................................................8 Acknowledgments..................................................8 Author's Addresses...............................................8 1. Introduction Work is currently ongoing in the Traffic Engineering Working Group to provide the capability for Diffserv-aware MPLS traffic engineering (DS-TE) [3, 4]. A major item is the specification of bandwidth constraint models for use with DS-TE. This document is intended to complement the Requirements document [3] by describing the implications of some of the criteria for selecting a default model. Properties of different models are also presented to provide guidance to the Solution document [4] for this selection. The following selection criteria are currently listed in the Requirements document: (1) addresses the scenarios in Section 2 (of [3]) (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 Also, two bandwidth constraint models are described in the Requirements document: (1) explicit maximum allocation - the maximum allowable bandwidth usage of each class is being explicitly specified (2) Russian Doll - specification of maximum allowable usage is being done cumulatively by grouping successive priority classes The use of any given bandwidth constraint model has significant impacts on the performance of a network, as to be explained later. Therefore, the criteria used to select a model must Lai Expires - December 2002 [Page 2] BC Models for Diffserv-aware MPLS TE June 2002 enable us to evaluate how a particular model delivers its performance, relative to other models. This version of the present document deals with criteria (2) and (5) only. Criteria (3) and (4) are to be included in the next version. Criterion (1) relates mainly to the Requirements document and will not be further discussed. 2. Performance Under Normal Load To understand the implications of using criteria (3) and (5) to select a bandwidth constraint model, we first present some numerical results of our analysis. This is to gain some insight to facilitate the discussion of the issues that can arise. To simplify our presentation, we assume that (1) there are only three classes of traffic, and (2) all 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. Let the three classes of traffic be denoted as class 1 (highest priority), class 2, and class 3 (lowest priority). 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. As an 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. For the explicit maximum allocation model, we assume that the constraints are: 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 the Russian Doll model, we assume that the constraints are: 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. Lai Expires - December 2002 [Page 3] BC Models for Diffserv-aware MPLS TE June 2002 Obviously, these should not be regarded as typical values used by any Internet 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. In the example here, the values of these parameters are chosen so that, under normal conditions, the performance of the two models is similar in terms of their blocking and preemption behavior for LSP setup requests. Specifically, the following table shows their relative performance. Table 1. Blocking and preemption probabilities Model PB1 PB2 PB3 PP2 PP3 PB2+PP2 PB3+PP3 MaxAll 0.03692 0.03961 0.02384 0 0.02275 0.03961 0.04659 RussDoll 0.03692 0.02296 0.02402 0.01578 0.01611 0.03874 0.04013 In the above table, 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 From column 2 of the above table, it can be seen that class 1 sees the same blocking under both models. This should be obvious since both allocate up to 6 simultaneous LSPs for use by class 1 only. Slightly better results are obtained from the Russian Doll model, as shown by the last two columns in Table 1. This comes about because the cascaded bandwidth separation in the Russian Doll design effectively gives class 3 some form of protection from being preempted by higher priority classes. It is interesting to compare these results with that 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 model 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. Lai Expires - December 2002 [Page 4] BC Models for Diffserv-aware MPLS TE June 2002 3. Performance Under OverLoad To investigate the performance under overload conditions, the load of each class in the above example is varied separately. Figures 1 and 2 show their relative performance. 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 correspondingly increased. Here is something common to both algorithms: 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 algorithms: being none in one case and significant in the other. 1. While class 2 sees no improvement in performance when class 1 traffic is below normal when the explicit maximum allocation algorithm is used, it sees better than normal performance under the Russian Doll algorithm. 2. Class 2 sees no degradation in performance when class 1 traffic is above normal when the explicit maximum allocation algorithm is used. In this example, with bandwidth constraints 6 + 7 < 15, class 1 and class 2 traffic are 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, 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 MaxAll. Lai Expires - December 2002 [Page 5] BC Models for Diffserv-aware MPLS TE June 2002 3. This is not the case in the Russian Doll algorithm. 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 1 and class 2 traffic are sharing their bandwidth allocations to some extent. Consequently, class 2 suffers when class 1 traffic increases. Thus, it appears that while the cascaded bandwidth arrangement and the resulting bandwidth sharing makes the Russian Doll algorithm works better under normal conditions, such interaction makes it less effective to provide service isolation under overload conditions. 4. Performance Under Complete Sharing As observed towards the end of Section 2, the partitioning of bandwidth capacity for access by different traffic classes tends to reduce the maximum link efficiency achievable. We now consider the case where there is no such partitioning, thereby resulting in complete sharing of the total bandwidth among all the classes. For the explicit maximum allocation model, this means that the constraints are such that up to 15 simultaneous LSPs are allowed for any class. Similarly, for the Russian Doll model, the constraints are 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. Effectively, there is now no distinction between the two models. Figure 3 shows the performance when all classes have equal access to link bandwidth under the complete sharing scheme. With preemption being enabled, it can be seen that class 1 virtually sees no blocking, regardless of the loading conditions of the link. Since class 2 can only preempt class 3, class 2 sees some blocking and/or preemption when either class 1 load or its own load is above normal; otherwise, class 2 is unaffected by increases of class 3 load. As higher priority classes always preempt class 3 when the link is full, class 3 suffers the most with high blocking/preemption when there is any load increase from any class. A comparison of Figures 1, 2, and 3 shows that, while the performance of both classes 1 and 2 is far superior under complete sharing, class 3 performance is much better off under either the explicit maximum allocation or Russian Doll models. In a sense, class 3 is starved under overload as no Lai Expires - December 2002 [Page 6] BC Models for Diffserv-aware MPLS TE June 2002 protection of its service is being provided under complete sharing. 5. Implications on Selection Criteria Based on the previous results, a general theme is shown to be the trade-off between bandwidth sharing and service protection/isolation. To show this more concretely, let us compare the different models in terms of the *overall loss probability*. This quantity is defined as the long-term proportion of LSP requests from all classes combined that are lost as a result of either blocking or preemption. As noted from the previous sections, while the Russian Doll model has a higher degree of sharing then explicit maximum allocation, both converge ultimately to the complete sharing model as the degree of sharing in each of them is increased. Figure 4 shows that the overall loss probability is the smallest under complete sharing and the largest under explicit maximum allocation, with Russian Doll being intermediate. Expressed differently, complete sharing yields the highest link efficiency and explicit maximum allocation the lowest. As a matter of fact, the overall loss probability of complete sharing is identical to loss probability of a single class as computed by the Erlang loss formula. Yet complete sharing has the poorest service protection capability. Increasing the degree of bandwidth sharing among the different traffic classes helps to increase link efficiency. Such increase, however, will lead to a tighter coupling between different classes. Under normal loading conditions, proper dimensioning of the link so that there is adequate capacity for each class can minimize the effect of such coupling. Under overload conditions, when there is a scarcity of capacity, such coupling will be unavoidable and can cause severe degradation of service to the lower priority classes. Thus, the objective of maximizing link usage as stated in selection criterion (5) must be exercised with care, with due consideration to the effect of interactions among the different classes. Otherwise, use of this criterion alone will lead to the selection of the complete sharing scheme, as shown in Figure 4. The intention of criterion (2) in judging the effectiveness of different models is to evaluate how they help the network to achieve the expected performance. This can be expressed in terms of the blocking and/or preemption behavior as seen by different classes under various loading conditions. For example, the relative strength of a model can be demonstrated by Lai Expires - December 2002 [Page 7] BC Models for Diffserv-aware MPLS TE June 2002 examining how many times the per-class blocking or preemption probability under overload is worse off than the corresponding probability under normal load. Security Considerations No new security considerations are raised by this document, as they are the same as the DS-TE requirements document [3]. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 3 F. Le Faucheur, T. Nadeau, M. Tatham, T. Telkamp, D. Cooper, J. Boyle, W. Lai, L. Fang, G. Ash, P. Hicks, A. Chiu, W. Townsend, and D. Skalecki, "Requirements for Support of Diff- Serv-aware MPLS Traffic Engineering," Internet-Draft, Work in Progress, April 2002. 4 F. Le Faucheur, T. Nadeau, J. Boyle, K. Kompella, W. Townsend, and D. Skalecki, "Protocol extensions for support of Diff-Serv-aware MPLS Traffic Engineering," Internet-Draft, Work in Progress, February 2002. Acknowledgments To be added. Author's Addresses Wai Sum Lai AT&T 200 Laurel Avenue Middletown, NJ 07748, USA Phone: +1 732-420-3712 Email: wlai@att.com Lai Expires - December 2002 [Page 8]