Fair intelligent admission control over resource-feedback DiffServ network

Computer Communications 28 (2005) 1770–1777 www.elsevier.com/locate/comcom

Fair intelligent admission control over resource-feedback DiffServ network Ming Li*, Doan B. Hoang, Andrew J. Simmonds Faculty of Information Technology, University of Technology, Sydney, NSW, Australia Received 3 December 2004; accepted 3 December 2004 Available online 13 January 2005

Abstract The basic DiffServ model lacks mechanisms to prevent itself from being overloaded and to inform its internal capability to the external world. This paper addresses the problem by presenting a Fair Intelligent Admission Control (FIAC) over an enhanced-DiffServ architecture. The central idea is to make admission decision based on both informed internal network QoS states and the external traffic QoS requirements at the edge node. This model has several advantages: (1) it is backward compatible with DiffServ, (2) it adapts to traffic load and network QoS state changes, and (3) it provides interactive communication between the external QoS requirements and the internal DiffServ network capability. In this paper, we use simulation to evaluate the performance of DiffServ with or without FIAC. The performance demonstrates that the new scheme is able to admit traffic fairly and achieve edge-to-edge QoS under heavy traffic conditions and network state changes. q 2005 Published by Elsevier B.V. Keywords: DiffServ; QoS; Admission control; Resource discovery

1. Introduction Efforts to provide Quality of Service (QoS) for the Internet have led to two distinct approaches: the Integrated Service (IntServ) and the Differentiated Service (DiffServ). The goal of IntServ is to provide per-flow end-to-end QoS [8]. The IntServ architecture needs an explicit setup mechanism to convey information to routers so that they can provision resources to the requested services. The resource requirements for running per-flow resource reservations on routers increase proportionally to the number of separate reservations that need to be accommodated. The use of perflow state and per-flow processing is thus not feasible across the high-speed core of a network. In contrast, the DiffServ architecture [9] achieves scalability by limiting QoS functionalities to class-based priority mechanisms. DiffServ makes a distinction between operations performed in the core of the network, and operations at the edges of the network, scheduling and * Corresponding author. Tel.: C61 2 9514 4609; fax: C61 2 9514 1807. E-mail addresses: [email protected] (M. Li), [email protected] (D.B. Hoang), [email protected] (A.J. Simmonds). 0140-3664/$ - see front matter q 2005 Published by Elsevier B.V. doi:10.1016/j.comcom.2004.12.022

queue management only deal with a few classes of traffic, and can thus remain relatively simple. The DiffServ architecture is composed of a number of functional elements: packet classifier, traffic conditioner and per-hop forwarding behaviors (PHB). The PHB determines the priority in terms of DiffServ codepoint (DSCP). There are two types of PHBs besides the default best-effort service: expedited forwarding (EF) PHB and assured forwarding (AF) PHB [10]. The Assured Forwarding service provides qualitative differentiation among the AF classes. Expedited Forwarding service is intended to provide low-delay, lowjitter, and low-loss services by ensuring that EF aggregate is served at a certain configured rate. However, it has been observed that traditional DiffServ, e.g. RIO-based scheme [1], exposes the unfair allocation of the network bandwidth among the Assured Forwarding services in case of different Round Trip Time (RTT), UDP/ TCP interaction, network provision state changes, and unfair for micro flows inside the aggregate. This is because the traditional DiffServ is unaware of its internal network QoS states. Even if the ‘internal’ network is in congestion state, the DiffServ still forwards the overloading traffic into the network, worsening the congestion situation.

M. Li et al. / Computer Communications 28 (2005) 1770–1777

To address the above problems and provide stronger QoS without sacrificing scalability, we have designed Fair Intelligent Admission Control (FIAC) over DiffServ architecture. In this scheme, admission control decisions are performed at the edge router based on QoS requirement and the feedback of the current network capability state which is provided by the enhanced DiffServ [4]. The admission control decisions are made solely at the ingress edge router; per-flow state is not maintained in the network core router, and there is no coordination of state with core nodes. Therefore, admission control is performed in a scalable way. Second, the admission control over DiffServ is fully compatible with the DiffServ framework without any change in DiffServ domain. The most advantage of this approach is that it is able to make predictable admission control to converge to the optimum point which satisfies the ‘external’ traffic requirements and the internal network capability. Furthermore, FIAC over DiffServ allows DiffServ domain administrator to adjust policy to meet end-toend QoS requirements. The paper is organized as follows. Section 2 discusses some related work. Section 3 introduces the FIAC over DiffServ network model. Section 4 presents the Resource Discovery Protocol over DiffServ. In Section 5, we introduce Fair Intelligent Admission Control Module. In Section 6, we simulate FIAC over DiffServ to assess its performance against traditional DiffServ model. Section 7 concludes with suggestions for future work.

2. Related work Over the last 2 years, several research efforts have been made to find ideal service architecture, that is, the service architecture which combines the advantages of DiffServ and IntServ De Meer et al. [2] provided an analysis of existing IP quality of service solutions and the implied signaling issues. It is pointed out that an improvement to the QoS DiffServ architecture could be achieved by providing congestion signaling from within a DiffServ domain to the boundary between the two administrative domains. It is also believed that feedback and signaling are needed in the next generation of a DiffServ architecture that delivers its specified classes of service by a combination of resource provisioning and cooperation with the subscribers. Our proposal addresses these issues. Zhang et al. [13] proposed a new Bandwidth Broker (BB) architecture to manage all the reservation states and store the network information. The drawback of this approach is that it is difficult for the BB to manage all the information and make admission decisions of a large network. In addition, it estimates network available resource in the worst case, which can not efficiently utilize network resource. Jeong et al. [5] proposed a set of router-based QoS mechanism including queue policy, resource reservation

1771

and metering using the enforcement of traffic profile. The proposed queue policy is to ensure that UDP flows get required bandwidth and TCP flows are protected from unresponsive UDP flows. The proposal only considered simple buffer partitions for allocating bandwidth. Our scheme uses fair intelligent admission control mechanisms at the edge router to dynamically adjust incoming class traffic. Gerla et al. [3] considered bandwidth feedback control of TCP and real time sources in the Internet. The end hosts use this information to adjust their congestion window. However, their scheme needs to modify current TCP protocol by adding one state variable to store the round trip propagation delay and the available bandwidth-delay product. Our scheme is transparent to TCP, requires no modification to current TCP implementation. Qiu and Knightly [7] proposed endpoint admission control (EPAC) scheme should convey the congestion status of network nodes to the end-points. If the metric is below the threshold, the host admits the flow and starts data transmission; otherwise, the flow is rejected. However, the EPAC scheme does not provide adequate information to the endpoints to utilize network resource efficiently. Traffic without congestion control (e.g. UDP traffic) can still manage to have unfair advantage over congestion-controlled traffic (e.g. TCP traffic). Kumar et al. [6] proposed an intelligent marker, which relies on an similar Explicit Congestion Notification (ECN) feedback control mechanism. The marker uses a congestion factor to calculate marking probability. The proposal only considers congestion status as 1 or 0 without indicating congestion degree. Our scheme improves network utilization by using a factor proportional to the degree of congestion.

3. FIAC over extended DiffServ network model The problem of traffic overloading and network state changes for DiffServ is due to DiffServ being unaware of internal network capability. The aims of FIAC over DiffServ are: (a) to setup a communication channel between internal (the network capability) and external (the traffic QoS requirements), (b) to make admission decision based on internal (network capability) and external (the traffic QoS requirements). We developed two additional modules to implement the above two goals: (a) Resource Discovery Protocol over DiffServ; (b) Fair Intelligent Admission Control module. Fig. 1 illustrates the relationship between these two components. The Resource Discovery (RD) module performs two functions: first, it is responsible for generating RD packets to collect ‘en route’ QoS states; second, it communicates with admission control module by reporting dynamic internal network capability.

1772

M. Li et al. / Computer Communications 28 (2005) 1770–1777

Fig. 1. FIAC over DiffServ components.

The Admission Control Module makes admission decision based on the internal network capability report from the RD protocol and external traffic QoS requirements. For each DiffServ domain, the ingress edge router generates the Resource Discovery (RD) packets destined for the egress edge router and assigns RD packets a special class (e.g. EF class). The RD packets contain a vector of QoS parameters for all classes along the path. Upon receiving a RD packet, the core router consults its QoS states in terms of class and modifies the fields of the RD packets accordingly and then forwards the RD packet to other routers along the path to the egress router. The egress router is responsible for sending back the RD packet to the ingress router with latest the network QoS states. The ingress router makes admission decision by applying Fair Intelligent Admission Control (FIAC) algorithm. If the QoS requirements are supported by the network capability, the connection will be admitted; otherwise, FIAC will take the rejection functions (e.g. drop, reshape, etc.) for the incoming traffic according to the DiffServ internal network capability. We limit our discussion on the relative per-class service differentiation. We will present details for the two additional components of FIAC over DiffServ in the following sections.

4. Resource discovery protocol over DiffServ Basically, the Resource Discovery Protocol is used to generate Resource Discovery (RD) packets for collecting the current network QoS states. The DiffServ domain administrator can assign the DSCP (e.g. EF class) to RD traffic. The DiffServ router is extended to include the QoS state monitoring function. Upon receiving a RD packet, the router consults its QoS state and modifies the fields of the RD packets accordingly and then forwards the RD packet to other router along the path to the egress edge router. The egress edge router is responsible for sending back the RD packet to ingress edge router. Fig. 2 illustrates the Resource Discovery Protocol structure and relationship with normal DiffServ components. The Resource Discovery Protocol is a closed-loop feedback

mechanism working between ingress edge router and egress edge router. On the forward path, ingress edge routers perform two functions. They (a) initiate the RD packet, mark the DSCP (e.g. EF class) in the DSCP-field of RD packet, and (b) generate RD packet in a constant rate (or proportional to incoming traffic rate). In turn, the core routers forward RD packets to collect the network QoS state information. On the backward path, egress edge routers terminate the RD packet and send them back to ingress edge router with updated network QoS state information along the path. Upon receiving backward RD packets, ingress edge routers report the network capability to the Admission Control Module. As a result, the Resource Discovery Protocol can provide internal network capability information dynamically. In Sections 4.1 and 4.2, we will discuss the Resource Discovery Protocol in terms of overhead and QoS state measurement. 4.1. RD packet generation and overhead In order to collect the QoS states of network along the path, our RD mechanisms require packets to carry state in their headers. The main challenge to implementing these algorithms is to use minimum space for storing QoS states variables and at the same time remain fully compatible with current standards and protocols. In particular, we want the network domain to be transparent to end-to-end protocols, i.e. the egress router should feedback the RD packet to the ingress router. There are three pieces of state that need to be

Fig. 2. Resource Discovery Protocol.

M. Li et al. / Computer Communications 28 (2005) 1770–1777

1773

Fig. 3. RD packet format.

encoded in a RD packet: (1) the direction of RD packet which specifies the RD packet in forward or backward path, (2) the DSCP field contains the aggregate classification assigned by the ingress edge router, (3) the Mean Explicit Rate (MER) field provides Mean Explicit Rate per classunit. Fig. 3 shows the RD packet format. The bits of the RD packet are allocated to the following fields: † a 1-bit flag, called DIRECTION, that specifies the RD packet in forward or backward path † a 2-bit field DSCP that contains the aggregate classification assigned by the ingress router † a 12-bit field MER that encodes QoS states. We express the overhead calculation O as in (1). OZ

Rrd P Rrd C niZ1 Ri

(1)

where Rrd is the RD traffic rate, Ri is for other traffic rate, and n is the number of classes except RD traffic. In our experiment, we set RD traffic as EF traffic with 20 kbps bandwidth guarantee, which is around 2% of the total link bandwidth, 1 Mbps. From the (1), the overhead is no more than 2%. The domain administrator can adjust RD traffic according to the domain states. For example, the RD packets could be assigned as low priority class (e.g. Bronze service) and low sending rate if the incoming traffic behaves well; the RD packets could be assigned as high priority (e.g. Gold or Premium service) and high sending rate if the network states varies dramatically. 4.2. QoS state measurement Upon receiving RD packet, the core routers measure QoS states and update RD fields. To estimate the QoS state, Mean Explicit Rate, we take into account the available bandwidth state and the available buffer state. The Available Bandwidth Fair Control Function is designed to calculate the fairshare of available bandwidth. The Queue Control Function expresses the degree of network congestion it can tolerate. We use exponential averaging formula as in CSFQ [11] to estimate the incoming traffic rate. If we indicate the arrival time of the kth packet of class i as Tik and its length as lki ðtÞ, the new estimation of arriving rate Ri(t) can be

computed as follows: KTi =K Þ* Rnew i ðtÞ Z ð1 K e k

k lki C eKTi =K  Rold i k Ti

(2)

where Tik represents the kth sample of the inter-arrival time of class traffic i, i.e. Tik Z tik K tikK1 and k is a constant, 400 ms. To calculate Mean Available Rate (MAR), we designed the function as follows. 8 if ðQ% Q0 Þ or ðQO Q0 and Ri % MARold Þ > > > > < MAR C b ðR K MAR Þ old old * i MARnew Z > else > > > : MARold (3) where b is the average factor which determines the dependency range on variation and recent history. The value of MAR is a running average of the current load when the network operates below the target operating point. When the queue length exceeds the target operating point, Q0, it does not allow MAR to increase further. The Queue Control Function is defined as in the following equation. 8 Buffer_size K Q > > ; > < Buffer_size K Q0 ðl K 1Þ * ðQ0 K QÞ f ðQÞ Z > ; 1C > > Q0 : 1;

if Q0 % Q if 0% Q% Q0

(4)

if Q Z 0

The parameter, l, can be considered as an oversell the network factor when it is in under-utilized. Q0 is configured as in-profile threshold. The Q0 is the target point at which the queue control function expects to maintain. When the queue length is beyond the target (QRQ0), that means the network becomes highly loaded, risking long delay and buffer overflow, it will discourage the incoming traffic (f(Q)%1). The QoS states, Mean Explicit Rate, is defined as follows: MERi Z f ðQÞ * MARi

(5)

1774

M. Li et al. / Computer Communications 28 (2005) 1770–1777

The Mean Explicit Rate (MERi) reflects network capability for class i. Refer to [4] for detailed discussion.

5. Fair intelligent admission control module After receiving QoS report from Resource Discovery Protocol, the Admission Control Module estimates the incoming class traffic and applies Fair Intelligent Admission Control (FIAC) algorithm to make admission decision The philosophy behind FIAC is to handle the overloading traffic as early as possible. In turn, the congestion could be prevented as early as possible. The objective of FIAC is to guarantee a fair amount of the network bandwidth allocation among classes according to relative per-class QoS requirements and network capability. FIAC is a predictive control scheme which performs two functions: (a) it estimates the amount of class traffic expected to flow into the domain based on history of the traffic, and (b) it makes admission decision in terms of incoming class traffic and network capability. We set queue threshold Q0 as Q0 Z r * BufferSizei

(6)

where r is queue utilization ratio which is set by DiffServ domain administrator and BufferSizei denotes the queue size for class i. The queue length threshold, Q0, is considered as optimal control level. FIAC algorithm holds some amount of buffer space in reserve for bursty traffic and overloading traffic. The queue length variation function f(Q(t)) considers queue variation around Q0 8 QSi K Qi ðtÞ > > if Qi ðtÞO Q0 < QSi K Q0 (7) f ðQðtÞÞ Z Q0 K Qi ðtÞ > > if Qi ðtÞ% Q0 : 1 C a* Q 0

where a is the sensitive factor of the distance to the queue threshold, Q0. The basic characteristics of the queue variation function (7) is that it should have a value equal to 1 when the queue length is equal to Q0, and a value less/ larger than 1 when the queue length is larger/less than Q0,

and its value reflects the future network resource potential. The queue control function (7) will encourage more packets into the network if its value is greater than 1 (it means the network has more capability potential); otherwise (it means the network has less capability potential), it will discourage packets into network till to be within the network capability range. The queue control function is desired to produce proper effect on the queue fluctuation and smooth traffic loading into DiffServ domain. FIAC uses Mean Explicit Rate (MERi), and queue control function (7) as the decision parameters to calculate the admission rate for class i as follows: R0 Z f ðQðtÞÞ * MERi

(8)

If the incoming traffic rate of class i, from Eq. (2), is less than R0, the packet will be allowed into DiffServ network; otherwise the packet will be rejected. FIAC algorithm adapts to changes in terms of network capability and traffic conditions. Whenever network congestion occurs, the queue length Qi(t) will grow and the network capability rate MERi will decrease. The incoming traffic will be rejected if the incoming rate Ri(t) exceeds the product of MERi and f(Q(t)), while the Admission Control Module will drain, free up more buffer and alleviate network congestion. Eventually the queue will stabilize at queue threshold.

6. Fair intelligent admission control over DiffServ evaluation In this section, we evaluate the performance of FIAC over DiffServ design. All simulations were performed in NS-2 [12], and are based on FIAC-DiffServ architecture, which we developed as an enhanced DiffServ module. The parking-lot configuration (see Fig. 4) is set up to study the behavior with overloading traffic. Some traffic traverses Ingress1/Core/Egress/D1, and other traffic traverses Ingress2/Core/Egress/D2. The inter-router link (Core/Egress) is the bottleneck link. The bandwidth of bottleneck link is 1 Mbps and others link is 100 Mbps. The link delay is set to 2 ms for all links. Ingress1 and Ingress2 were configured as DiffServ ingress edge routers.

Fig. 4. Parking-lot topology.

M. Li et al. / Computer Communications 28 (2005) 1770–1777

1775

Table 1 Class specification and traffic characteristics Class

PHB

Traffic type

Bandwidth

DSCP

Premium Gold Silver Bronze Best effort

EF AF11, AF12 AF21, AF22 AF31, AF32 Default

RD UDP(CBR) FTP Telnet CBR

20 kbps 40 % 30 % 20 % 10 %

40 10, 12 20, 22 30, 32 0

Router Egress was configured as DiffServ egress edge router. Router Core was configured as DiffServ core router. The goal of the experiment is to study bandwidth allocation for different AF classes (e.g. Gold service, Silver service, and Bronze service) under traffic overloading situation. The class specification and traffic characteristics are shown in Table 1. Consider the topology in Fig. 4. The RD packets (EF class) are generated at Ingress1 and Ingress2 at a constant rate, 10 kbps, to be used to probe network capability state. Two UDP (CBR) traffic are generated at S1 and S2, which traverse the common bottle link (Core/Egress) to go to the different destinations, S1/D1 and S2/D2. The FTP traffic is generated using default value and Telnet traffic is generated using the tcplib distribution for the inter-arrival time. The 10 FTP connections and 10 Telnet connections are attached to S1/ Ingress1/Core/Egress/D1 path and another 10 FTP connections and 10 Telnet connections are attached to S2/ Ingress2/Core/Egress/D2 path. Both FTP and Telnet traffics are activated during the first 5 s of simulation. Background traffic is sent as CBR flow from S1 to D1 and S2 to D2 in a way that the default queue is always full. The traffic information is shown in Table 2. In this scenario, UDP traffic (AF11 class) is overloading into DiffServ domain. For FIAC over DiffServ, AF11 (Gold service), AF21 (Silver service), and AF31 (Bronze service) queues threshold, Q0, is set to 60 packets to be the same as INprofile threshold. No packet is dropped in the middle of the network with FIAC over DiffServ scheme. 6.1. Differentiation comparison for AF PHB in traffic overloading situation

Fig. 5. Goodput for DiffServ and FIAC over DiffServ.

bandwidth (730 kbps) than Service Level Agreement (SLA) specified (40% of remaining bandwidth, around 396 kbps). Also, AF21 (Silver service) and AF31 (Bronze service) TCP based traffic could not get expected service. It can be concluded that DiffServ on its own could not achieve edge-to-edge QoS guarantee in traffic overloading situation. For FIAC over DiffServ, Fig. 5 shows that AF11, AF21, and AF31 classes were allocated bandwidth close to class specification, refer to Table 1. It is worth noting that overhead of FIAC (EF traffic, RD packets) is only 2% of total bandwidth. In our experiment, we investigated different rate to assign EF traffic (RD packets). The results show that the scheme with 20 kbps rate of RD packets provides most efficient control comparing to the DiffServ without admission control. 6.2. Parameter sensitivity Most congestion control schemes provide parameters that can be tuned to the environment. A good scheme must provide a set of parameters that offer the desired level of control. However, the number of parameters should be kept small and easy to set to limit the complexity. The parameters must be relatively insensitive to minor changes in network characteristics. We investigated the sensitivity of the parameters in the parking-lot configuration. For the sensitivity of a in (7), the effective goodput with different a is shown as in Fig. 6. With different a, the goodput of AF classes is still maintained according to the class specification. These simulation results show that a is 0.15 is the optimal point for FIAC.

Fig 5 displays that AF11 (Gold service) class traffic (UDP traffic), which is overloading, received more Table 2 Traffic information PHB

Path 1 (Ingress1/Core/ Egress/D1)

Path 2 (Ingress2/Core/ Egress/D2)

EF AF11 AF21 AF31 Default

RD (10 kbps) UDP (1 Mbps) 10 FTP flows 10 Telnet flows CBR (500 kbps)

RD (10 kbps) UDP (1 Mbps) 10 FTP flows 10 Telnet flows CBR (500 kbps)

Fig. 6. Sensitivity of FIAC parameter setting.

1776

M. Li et al. / Computer Communications 28 (2005) 1770–1777

the threshold, therefore the network is stable and adaptable to network capability.

7. Discussion and conclusion

Fig. 7. Bottleneck queue length (AF11 Queue).

Fig. 8. Queue length variation at ingress edge.

Parameter l, in (4) is set within the range of 1.01 to 1.9 and parameter b in (3) is set within the range of 0.03 to 0.06. In the Fair Intelligent Admission Control, linear queue control functions are employed. The curves of linear functions change smoothly with queue change. The MAR allocation is consistent and the resulting MAR fluctuates consistently and smoothly around the optimal point. Minor change on parameters has minor impact on the curves and the following control effect. Therefore minor parameter mistuning won’t degrade the control effect and the network performance. This scheme is robust and relatively insensitive to parameter setting.

The paper proposes FIAC over DiffServ scheme for providing tighter edge-to-edge QoS responses under heavy traffic loads in the underlying network. It intelligently resolves the mismatches between QoS requirements of traffic class and network capacity at an edge node. The scheme relies on a capability discovery loop between ingress edge and egress edge. With our approach the QoS parameters discovered are not global since the loop only has a partial view of the network. Global information can be obtained with QoS-routing where QoS parameters and cost functions are flooded to all routers frequently. However, QoS routing suffers several serious problems, namely, NPcompletion, instability, and cost. Simulations show that in the limited scenario the FIAC over DiffServ does the right thing. However, more extensive simulations are needed to determine whether the FIAC parameters are reasonable or not. It has been found that the FIAC parameters are sensitive to flow number, traffic pattern, and number of class in terms of throughput. In conclusion, it is feasible to introduce the FIAC over resource-feedback DiffServ model into the existing Internet infrastructure to provide efficient, fair, and more accurate QoS service. We plan to employ our scheme to provide efficient admission control over multiple DiffServ domains and to derive end-to-end QoS for various applications.

References 6.3. Queue length variation at the bottleneck and at the ingress We studied the bottleneck queue length variation for AF11 class. Fig. 7 shows that DiffServ without admission control, the queue length fluctuates widely. With FIAC, the queue length varies smoothly and narrowly around the optimal operation point, 60 packets. Now we look at the AF11 queue length at the ingress edge router while AF11 class traffic is in overloading condition, 1 Mbps. Fig. 8 shows the queue length variation with FIAC. For the traffic pattern that we studied, the optimal setting for the FIAC factor a in (7) ranges from 0.031 to 0.13, and fixing a (0.125) in that range does a reasonable good job with queue size, 80 packets (512 b/packet). The threshold, Q0, is set to 10 packets. FIAC makes the queue fluctuation is smooth and around

[1] D. Clark, W. Fang, Explicit allocation of best-effort packet delivery service, IEEE/ACM Transaction on Networking 6 (4) (1998) 362– 373. [2] H. De Meer, P. O’Hanlon, G. Feher, N. Blefari-Melazzi, H. Tschofenig, G. Karagiannis, D. Partain, V. Rexhepi, L. Westberg, Analysis of existing QoS solutions, an expedited forwarding PHB group, IETF Internet Draft draftdemeer-nsisanalysis-02.txt, 2002. [3] M. Gerla, W. Weng, R.L. Cign, Bandwidth feedback control of TCP and real time sources in the internet, Proceeding of IEEE Globecom’00, San Francisco, CA, USA, 2000. [4] D.B. Hoang, M. Li, FICC-DS: a resource discovery and control scheme for DiffServ, Proceeding of ICT’03, Bankok, Thailand, 2003. [5] S.H. Jeong, H. Owen, J. Copeland, J. Sokol, QoS Support for UDP/TCP based networks, Computer Communications 24 (2001) 64– 77. [6] K.R.R. Kumar, A.L. Ananda, L. Jacob, Using edge-to-edge feedback control to make assured service more assured in DiffServ networks, Proceeding of LCN’2001 (2001).

M. Li et al. / Computer Communications 28 (2005) 1770–1777 [7] J. Qiu, E.W. Knightly, Measurement-based admission control with aggregate traffic envelopes, IEEE/ACM Transactions on Networking 9 (2001). [8] R. Braden, D. Clark, S. Shenker, Integrated service in the internet architecture: an overview, IETF RFC1633, 1994. [9] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, An architecture for differentiated service, IETF RFC2475, 1998. [10] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, Assured forwarding PHB group, IETF RFC2597, 1999.

1777

[11] I. Stoica, S. Shenker, H. Zhang, Core-stateless fair queueing: achieving approximately fair bandwidth allocation in high speed networks, Proceeding of ACM SIGCOMM’98, Vancouver, Canada, 1998. [12] VINT-Project, Network Simulator version 2, LBL (2000). [13] Z. Zhang, Z. Duan, L. Gao, Y. Hou, Decoupling QoS control from core router: a novel bandwidth broker architecture for scalable support of guaranteed service, Proceeding of ACM SIGCOMM’00, Stockholm, Sweden, 2000.