Fair Intelligent Admission Control over DiffServ Network

Transcription

1 Fair Intelligent Admission Control over DiffServ Network Ming Li, Doan B.Hoang and Andrew J. Simmonds Faculty of Information Technology, Unviersity of Technology, Sydney, NSW 2007, Australia Abstract The basic DiffServ model lacks mechanisms to prevent itself from being overload and to inform its internal capacity to the outside 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 network-status and 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 state changes, and (3) it provides interactive communication between QoS requirements and 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. Index Terms QoS, DiffServ, Admission Control. I. INTRODUCTION Efforts to provide Quality of Service (QoS) for the Internet has 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 [1]. The IntServ architecutre needs an explicit setup mechanism to convey information to routers so that they can provide the requested services to flows. The resource requirements for running per-flow resource reservations on routers increase in direct proportional 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 [2] achieves scalability by limiting QoS functionalities to class-based prority mechanisms. DiffServ makes a distinction between operations performed in the core of the network, and operations at the edges of the network, scheduling and 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 [3] and assured forwarding (AF) PHB [4]. The Assured Forwarding service provides qualitative differentation 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, without per-flow admission control, such an approach only supports weak QoS as compared to IntServ. To achieve 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 status which is provided by the enhanced DiffServ [5]. 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. Secondly, the admission control over DiffServ is fully compatible with the DiffServ framework without any chage in DiffServ domain. The most advantage of this approach is that it is able to make predictable admission control to support dynamic provisioning and traffic overloading. Furthermore, FIAC over DiffServ allows DiffServ domain administrator to adjust policy to meet end-to-end QoS requirements. It has been observed that traditional DiffServ can hardly achieve the desired edge-to-edge QoS under traffic overloading and network state changes (e.g. network provisioning change, sudden large traffic loads, congestion, etc.). This is because the traditional DiffServ is unaware of its internal network state. Even if the inside network is in congestion state, the DiffServ still forwards the overloading traffic into the network, worsening the congestion situation. We apply our admission control schemes to address this problem. The simulation results show our FIAC over DiffServ scheme can achieve better edge-to-edge QoS compared to DiffServ. 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. II. RELATED WORK Over the last two years, several research efforts have been made to find ideal service architecture, that is, a service architecture which combines the advantages of DiffServ and IntServ. De Meer, et al [6] 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

2 from within a DiffServ domain to the boundary between the two administrative domains. It is also believed that feedback and signaling is needed in the next generation of a DiffServ architecture that delivers its specified classes of service by a combination of resource provsioning and cooperation with the subscribers. Our proposal addresses these issues. Zhang, et al [7] 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 [8] proposed a set of router-based QoS mechanism including queue policy, resource reservation 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 [9] 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 and also can be applied to UDP traffic. Qiu and Knightly [10] 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 [11] proposed an intelligent marker, which relies on an similar Explicit Congestion Notification (ECN) feedback control mechanism. The marker uses a congestion factor provided by the control mechanism to calculate marking probability. The proposal only considers congestion status as 1 or 0 without indicating congestion degree. Our scheme applies fair intelligent admission control to improve network utilization by using a factor proportional to the degree of congestion. III. FIAC OVER DIFFSERV NETWORK MODEL The problem of traffic overloading and network state changes for DiffServ is due to DiffServ being unaware of inside network capability. The aims of FIAC over DiffServ are: (a) to setup a communication channel between inside (network capability) and outside (QoS requirements), (b) to make admission decision based on inside (network capability) and outside (QoS requirements). Admission control Module SLA Ingress router capability Fig. 1. control plane module Core router Data Plane Control Plane FIAC over DiffServ Components TABLE I RELATIVE PER-CLASS SERVICE DIFFERTIATION Traffic class PHB Bandwidth Premium EF 20 Kbps Gold AF11 40% Silver AF21 30% Bronze AF31 20% Best Effort Default 10% Egress router We developed two additional modules to implement the above two goals: (a) Resource Discovery Protocol over Diff- Serv; (b) Fair Intelligent Admission Control module. Fig. 1 illustrates the relationship between these two components. The Resource Discovery (RD) protocol performs two functions: firstly, it is responsible for generating RD packets to collect en router network QoS states; secondly, it communicates with admission control module by reporting dynamic internal network capability. The Admission Control Module makes admission decision based on the inside network capability report from the RD protocol and outside traffic QoS requirements. We limit our discussion on the relative per-class service differentiation. The set of relative per-class QoS requirements are given could be of the form in Table I. Where EF class is guaranteed bandwidth of 20 Kbps. AF11, AF21, and AF31 classes are set to 40%, 30%, and 20% of the remaining bandwidth. The best effort traffic is assigned 10% of the remaining bandwidth. The basic idea of FIAC over DiffServ is depicted in a schematic diagram in the middle of Fig. 2. Traffic arrived at the ingress router of the DiffServ is differentiated by its QoS requirements. All arriving traffic with the same QoS requirement (same class) is treated as an aggregate class. We assume that there are Q independent aggregate classes in the DiffServ domain. 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 to other routers along the path to the egress router. The egress router is responsible for sending back the RD packet to the ingress edge router. The ingress router makes admission decision by applying Fair Intelligent Admission Control (FIAC) algorithm. If the QoS requirements are sup-

3 (a) Flow aggregation: Per DiffServ Class 2= 3 >?8@ ; (b) Components of an End-to-End QoS Loop +, - % -. ) ( / (0 1* (c) Resource Discovery Loop Per DiffServ Region Fig. 2. RD Data E-R!! " # $ %'& () * * # * C-R ACB D D EGF'H IJACKGLNM9B O P Q R S T TUV P Q S S UW P QX S U ] ^ _ ` a ^b c bd efd _ ` g ]c h Y[Z \ E-R : ; 5< RD Loop Q i j kl m n'o n Q?p j kgq m rs o n'p tu v U Q v j kw m x ry'p tu z U Q?{ j kgs m } ~~ P } U FIAC over DiffServ Frame Work Model Core Router Fig. 3. QoS state reports RD packets Data Core router Resource Discovery Protocol 2 =3 ; 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 inside network capability information dynamically. In the following subsections, we will discuss the Resource Discovery Protocol in terms of overhead and QoS state measurement. A. RD Packet Generation and Overhead All RD packets bear the following information: < DSCP, DIRECTION, MER > The DSCP field (1 byte) contains the aggregate classification assigned by the ingress edge router. The DIRECTION (1 bit) field specifies the RD packet in forward or backward path. The MER field (10 bytes) provides Mean Explicit Rate per class-unit. The basic idea behind class-unit is the fact that indiviual class traffic with different weight (or priority) can be subdivided into smaller unit, which can be manipulated effectively. The smaller the class-unit is, the more sensitive the Resource Discovery Protocol responses to the network variation. In our experiment, we choose 10% of the total bandwidth as a class-unit. We express the overhead calculation O as in (1). ported by network capability, the connection will be admitted; otherwise, FIAC will handle the class traffic according to the DiffServ internal network capability (e.g. drop, reshape, etc.). We will present details for the two additional components of FIAC over DiffServ in the following sections. IV. RESOURCE DISCOVERY PROTOCOL OVER DIFFSERV Basically, the Resource Discovery Protocol is used to generate RD packets for collecting QoS states of network. 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. 3 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 O = R rd R rd + n i=1 R i Where R rd is the RD traffic rate, R i 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 DiffServ domain administrator can adjust RD traffic classification 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. B. 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 use exponential averaging formula as in CSFQ [12]. Using an exponential weight gives more reliable estimation for burst traffic, even when the packet inter-arrival time of the aggregate has significant variance. If we indicate the arrival time of the k th packet of class i as Ti k and its length as li k (t), the new estimation of arriving rate R i (t) can be computed as follows: Ri new (t) = (1 e T k i /K ) lk i Ti k (1) + e T k i /K R old i (2)

4 where Ti k represents the k th sample of the inter-arrival time of class traffic i, i.e., Ti k = t k i tk 1 i and k is a constant, 400 ms. In Resource Discovery Protocol, core routers calculate Mean Explicit Rate (MER i ) for class i, which reflects network capability for class i. Refer to [5] for detailed discussion. V. 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. Furthermore, FIAC algorithm guarantees that routers inside the DiffServ do not experience congestion. The ingress edge router may experience congestion when class traffics try to send more traffic than DiffServ network bandwidth available at the routers. Those class traffics trying to send more than per-class relative QoS requirements and network capability will not be allowed to DiffServ network. FIAC is a predictive control scheme which performs two functions: (a) it estimates the amount of class traffic expected to flow into DiffServ 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 length threshold Q 0 as follows. Q 0 = β QS i (3) Where β is queue utilization ratio which is set by DiffServ domain administrator and QS i denotes the queue size for class i. The queue length threshold, Q 0, 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 the threshold Q 0. f(q(t)) = { QSi Q i (t) QS i Q 0 if Q i (t) > Q α Q 0 Q i (t) (4) Q 0 if Q i (t) Q 0 where α is the sensitive factor of the distance to the queue threshold, Q 0. The basic characteristics of the queue variation function (4) is that it should have a value equal to 1 when the queue length is equal to Q 0, and a value less/larger than 1 when the queue length is larger/less than Q 0, and its value reflects the future network resource potential. The queue control function (4) 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. S1 E1 Fig. 4. S2 C E2 E Parking-lot Topology FIAC uses Mean Explicit Rate (MER i ), and queue control function (4) as the decision parameters to calculate the admission rate for class i as follows: D2 D1 R 0 = f(q(t)) MER i (5) If the incoming traffic rate of class i, from equaiton (2), is less than R 0, 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 Q i (t) will grow and the network capability rate MER i will decrease. The incoming traffic will be rejected if the incoming rate R i (t) exceeds the product of MER i and f(q(t)), while the Admission Control Module will drain, free up more buffer and alleviate network congestion. The idea behind FIAC algorithm is to control the class traffic to the threshold Q 0, which means optimal network utilization level. As we shall see, eventually the queue will stabilize at queue threshold. VI. 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 [13], and are based on FIAC-DiffServ architecture, which we developed as an enhanced DiffServ module. The NS-2 was chosen to implement FIAC over DiffServ because it already has the basic normal DiffServ module developed by Nortel [14]. The only additional modules required for FIAC over DiffServ are Resource Discovery Protocol and Admission Control Module. The parking-lot configuration (see Fig. 4) is set up to study the behavior of both DiffServ and FIAC over DiffServ with overloading traffic. Some traffic traverses E1 C E D1, and other traffic traverses E2 C E D2. The inter-router link (C E) is the bottleneck link. E1 and E2 were configured as DiffServ ingress edge routers. Router E was configured as DiffServ egress edge router. Router C was configured as DiffServ core router. The topology configuration is in Table II.

5 TABLE II PARKING-LOT TOPOLOGY CONFIGURATION DiffServ FIAC over DiffServ Link Bandwidth Delay E1 to C 100 Mbps 2 ms E2 to C 100 Mbps 2 ms C to E 1 Mbps 2 ms E to D1 100 Mbps 2 ms E to D2 100 Mbps 2 ms TABLE III CLASS SPECIFICATION AND TRAFFIC CHARACTERISTICS Goodput in Kbps EF Gold Service Silver Service Bronze Service Best Effort Class PHB Traffic Type Bandwidth DSCP Premium EF RD 20 Kbps 40 Gold AF11, AF12 UDP(CBR) 40% 10, 12 Silver AF21, AF22 FTP 30% 20, 22 Bronze AF31, AF32 Telnet 20% 30, 32 Best Effort Default CBR 10% 0 A. Class Specification and Traffic Characteristics 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 III Consider the topology in Fig. 4, router E1 and E2 are FIAC-DiffServ enabled ingress edge routers on their outgoing interface connected to core router C. The EF class (RD packets) are generated at E1 and E2 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 (C E) to go to the different destinations, S1 E1 C E D1 and S2 E2 C E 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 E1 C E D1 path and another 10 FTP connections and 10 Telnet connections are attached to S2 E2 C E D2 path. Both FTP and Telnet traffics are activated during the first 5 seconds 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 IV. 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, Q 0, is set to 60 packets to be the same as IN-profile threshold. No packet is dropped in the middle of the network with FIAC over DiffServ scheme. TABLE IV TRAFFIC INFORMATION PHB Path 1 (E1 C E D1) Path 2 (E2 C E D2) EF RD(10 Kbps) RD(10 Kbps) AF11 UDP(1 Mbps) UDP(1 Mbps) AF21 10 FTP flows 10 FTP flows AF31 10 Telnet flows 10 Telnet flows Default CBR(500 Kbps) CBR(500 Kbps) ' & % # $ "! Fig. 5. Fig. 6. Goodput for DiffServ and FIAC over DiffServ Sensitivity of FIAC Paremeter Setting B. Differentiation Comparison for AF PHB in Traffic Overloading Situation Fig. 5 displays that AF11 (Gold service) class traffic (UDP traffic), which is overloading, received more 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 III. 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. C. Parameter Sensitivity We investigated the sensitivity of the parameters in the parking-lot configuration. For the sensitivity of α in (4), the effective goodput with different α is shown as in Fig. 6. With different α, the goodput of AF classes is still maintained according to the class specification. These simulation results show that α is 0.15 is the optimal point for FIAC. D. Bottleneck Queue Length Variation We studied the bottleneck queue length variation for AF11 class. Fig. 7 shows that DiffServ without admission control, () () () * +

6 Queue Length (Pkts) Queue Length Fig. 7. (Pkts) Fig. 8. DiffServ FIAC over DiffServ Time (in seconds) Bottleneck Queue Length (AF11 Queue) AF11 queue length with FIAC AF11 queue length with FIAC Time (in seconds) Queue Length Variation at Ingress Edge the queue length fluctuates widely. With FIAC, the queue length varies smoothly and narrowly around the optimal operation point, 60 packets. E. Queue Length Variation at Ingress Edge 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 seeting for the FIAC factor α in (4) ranges from to 0.13, and fixing α (0.125) in that range does a reasonable good job with queue size, 80 packets (512 bytes/packet). The threshold, Q 0, is set to 10 packets. FIAC makes the queue fluctuation is smooth and around the threshold, therefore the network is stable and adaptable to network capability. VII. DISCUSSION AND CONCLUSION The paper proposes FIAC over DiffServ scheme for providing tighter edge-to-edge QoS responses under heavy traffic loads and in the underlying network conditions. It intelligently resolved the mismatches between QoS requirements of traffic class and network capacity at an edge node. The simulation results show that the scheme performs extremely well between edge nodes of a DiffServ domain. 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 in the networks frequently. However, QoS routing suffers several serious problems. Firstly, it is an NP-complete problem [15] when multiple cost metrics are employed. Some heuristic solutions are available (albeit complexity). Secondly, QoS routing suffers instability problem: the cost metric changes every time a connection is admitted to the network and it is almost impossible for each router to maintain a consistent global database required for an QoS algorithm. Thirdly, it is costly in terms of bandwidth used for flooding QoS information to all routers. For these reasons, we believe that our approach is pragmatic and deployable over the current DiffServ architecture. We plan to employ our scheme to provide efficient admission control over multiple DiffServ domains. Furthermore, work is underway to derive end-to-end QoS for various applications. The simulation shows that in the limited scenario the FIAC over DiffServ does the right thing. However, more extensive simulations are needed to see whether the FIAC parameters are reasonable or not. By our experience, 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 DiffServ model into the existing Internet infrastructure to provide efficient, fair, and more accurate QoS service. REFERENCES [1] R. Braden, D. Clark, and S. Shenker, Integrated Service in the Internet architecture: an overview, IETF RFC1633, [2] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, An architecture for Differentiated Service, IETF RFC2475, [3] V. Jacobson, K. Nichols, and K. Poduri, An expedited forwarding PHB group, IETF RFC2598, [4] J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski, Assured forwarding PHB group, IETF RFC2597, [5] D. B. Hoang and M. Li, FICC-DS: A Resource Discovery and Control Scheme for DiffServ, in Proceeding of ICT 03, Bankok, Thailand, [6] H. D. Meer, P. O Hanlon, G. Feher, N. Blefari-Melazzi, H. Tschofenig, G. Karagiannis, D. Partain, V. Rexhepi, and L. Westberg, Analysis of Existing QoS Solutions, IETF Internet Draft draft-demeer-nsis-analysis- 02.txt, [7] Z. Zhang, Z. Duan, L. Gao, and Y. Hou, Decoupling QoS Control from Core Router: a Novel Bandwidth Broker Architecture for Scalable Support of Guaranteed Service, in Proceeding of ACM SIGCOMM 00, Stockholm, Sweden, [8] S. H. Jeong, H. Owen, J. Copeland, and J. Sokol, QoS Support for UDP/TCP based Networks, Computer Communications, vol. 24, pp , [9] M. Gerla, W. Weng, and R. L. Cigno, Bandwidth Feedback Control of TCP and Real Time Sources in the Internet, in Proc. IEEE Globecom 00, San Francisco, CA, USA, [10] J. Qiu and E. W. Knightly, Measurement-based admission control with aggregate traffic envelopes, IEEE/ACM Transactions on Networking, vol. 9, [11] K. R. R. Kumar, A. L. Ananda, and L. Jacob, Using edge-to-edge Feedback Control to Make Assured Service more Assured in DiffServ Networks, in Proc. LCN 2001, [12] I. Stoica, S. Shenker, and H. Zhang, Core-stateless Fair Queueing: Achieving Approximately Fair Bandwidth Allocation in High Speed Networks, in Proceeding of ACM SIGCOMM 98, Vancouver, Canada, [13] VINT-Project, Network Simulator version 2 (NS-2), LBL, [14] F. Shallwani, J. Ethridge, P. Pieda, and M. Baines, Diff-Serv implementation for ns, [15] S. Chen and K. Nahrstedt, An Overview of Quality of Service Routing for Next-Generation High-Speed Networks: Problems and Solutions, IEEE Networks, vol. Nov/Dec, pp , 1998.