HYBRID ANALYTICAL/SIMULATION MECHANISM FOR ACCESS CONTROL AND ON-LINE BANDWIDTH OPTIMIZATION IN DIFFSERV ENVIRONMENTS

Transcription

1 HYBRID ANALYTICAL/SIMULATION MECHANISM FOR ACCESS CONTROL AND ON-LINE BANDWIDTH OPTIMIZATION IN DIFFSERV ENVIRONMENTS R. Bolla, F. Davoli, M. Perrando, M. Repetto Department of Communications, Computer and Systems Science (DIST) University of Genoa Via Opera Pia 13, I Genova, Italy Abstract - A multiservice IP network based on the DiffServ paradigm is considered, composed by Edge Routers (ER) and Core Routers (CR), forming a domain that is supervised by a Bandwidth Broker (BB). The traffic in the network belongs to three basic categories: Expedited Forwarding (EF), Assured Forwarding (AF) and Best- Effort (BE). Consistently with the DiffServ environment, CRs only treat aggregate flows; on the other hand, ERs keep per-flow information (from external sources or other network Domains), and convey it to the BB, which knows at each time instant the number (and the bandwidth requirements) of flows in progress within the domain for both EF and AF traffic categories. A global strategy for admission control, bandwidth allocation and routing within the domain is introduced and discussed in the paper. The aim is to minimize blocking of the "guaranteed" flows (EF and AF), while at the same time providing some resources also to BE traffic. As the main objective is to apply the above mentioned control actions on-line, a computational structure is sought, which allows a relatively fast implementation of the overall strategy. In particular, a mix of analytical and simulation tools is applied jointly: "locally optimal" bandwidth partitions for the traffic classes are determined over each link (which set the parameters of the link schedulers in the CRs, the routing metrics and admission control thresholds); a "high level" simulation (involving no packet-level operation) is performed, to determine the per-link traffic flows that would be induced by the given allocation; then, a new analytical computation is carried out, followed by a simulation run, until the allocations do not significantly change. The possible convergence of the scheme (under a fixed traffic pattern) is investigated and the results of its application under different traffic loads are studied on a test network. 1. Network architecture Today s Internet is a widely deployed network with hundreds of millions hosts, yet growing in size [1], connected by a network architecture belonging to different organizations. This results in a hierarchical organization, with the ASs (Autonomous Systems) at the top and interconnected to each other to form the backbone of the net. The internal structure of ASs can be also hierarchical, reducing the number of peers in every level, with many management benefits, such as simplifying IP addresses assignment to secondary Internet Service Provider (ISP) which also reduce IP routing table size, limiting control traffic to smaller area, and so on. This is very simple in Ipv6 [2], where the increased size of the address field allows great flexibility in assigning and partitioning the whole space. As an example of how a huge network can affect performance, we cite inter-domain (among ASs) routing, where BGP often fails to assure route stability and routing convergence [3],[4],[5].

2 For these reasons, we choose a hierarchical structure for our approach, and we assume to have few nodes on every level. At the bottom level, nodes correspond to hosts; at higher levels, nodes correspond to aggregates of nodes at lower levels. Such an architecture is very flexible: the same procedure can be used at every level, with the only difference on the aggregation size of the underling network traffics. From now on, we therefore deal only with the intra-level architecture. Basically, there are two opposite philosophies in the Internet to achieve Quality of Service (QoS) [6]: Integrated Services (IntServ) and Differentiated Services (DiffServ). IntServ tries to meet QoS requirements by reserving resources for every single flow along its path across the network, so that it can guarantee per-flow QoS. This is done by the RSVP signaling protocol ([7],[8]), and it becomes very heavy with many flows. DiffServ is quite different, as it identifies only several QoS classes, with different packet treatment; it aims at satisfying common-class QoS requirements, by controlling network resources at the nodes (Per Hop Behavior, PHB [9]). For example, this is done by setting suitable queue service disciplines, by limiting the amount of traffic in the network, by assigning different priorities, and by performing Call Admission Control (CAC). A central controller, denoted as Bandwidth Broker (BB), is dedicated to perform resource reservation, as well as to collect aggregate information for the upper levels. The BB can run on a dedicated machine or on a generic router and exchanges messages with the network nodes by some signaling protocols, in the same fashion as RSVP. We will analyze in detail in the following what kind of information the BB needs to exchange with the nodes in our proposal. We choose to implement three QoS classes: Expedited Forwarding (EF), Assured Forwarding (AF) and Best Effort (BE). EF is the maximum priority traffic in our network, and it should experience very low loss, latency and jitter while traversing the network [11]; such a service appears to the endpoints like a point-to-point connection, or a leased line. Users requiring this kind of service are asked to declare their peak rate, which (given that this service is presumed very expensive) we assume coinciding with their mean rate. Thus, users are classified in a limited number of classes, according to their mean rates. Classifiers and traffic conditioners (meters, markers, shapers and droppers) are required at the network edge to perform this task, as well as to verify the compliance of the users traffic to the agreement, but this is beyond our issues. AF is an intermediate class, with less pressing requirements on bandwidth, delay and jitter [1]. An AF user declares its mean transmission rate, from which we assign a maximum peak rate. The mean transmission rate is always guaranteed to users; better performance can be achieved if the network load is low. Thus, at the edge nodes, packets will be marked as high priority AF until they do not exceed the mean rate; surplus traffic will be marked as low priority AF. Also in this case users are classified in a fixed number of subclasses, based on their mean rate value. BE is the current Internet traffic with no guarantees on throughput, delay and jitter. 2. Resource allocation issues We have previously sketched our DiffServ network architecture; now we are going to explain how resources are shared among competitive traffic classes and how to achieve some form of fairness among the different traffic categories. First of all, a suitable queuing discipline is needed to achieve the required performance for every class: we choose to use different queues on each link, one for each kind of traffic. The EF queue is given priority on all the others; if we limit the amount of EF traffic in the network, this results in very low delay and jitter

3 experienced by these packets. Once the EF queue is empty, AF high priority traffic is served, while low priority packets are served only if there are still unused AF reserved resources. Finally, when all these queues are empty, BE traffic is served. Obviously, the performance experienced by the packets depends on the amount of traffic flows of each category admitted into the network: a CAC is necessary to achieve the QoS promised by the DiffServ architecture. With such a discipline, every queue is served at the maximum speed allowed by the link; our aim is to control the bandwidth reserved for each class on every link. Given the peak rate for EF traffic, we know in advance how many connections can be accepted not to exceed the reserved bandwidth. A similar consideration holds for AF, except that mean rates are taken instead of peak rates. Briefly, we fix two bandwidth thresholds on each link: one for EF and the other for AF; rates of flows traversing the link for each category can never exceed these thresholds. BE traffic can exploit at any time instant all the unused link bandwidth. This results in a complete partitioning CAC [21] for both EF and AF, but not for BE, whose upper bound is not fixed, but depends dynamically on the bandwidth left free from other traffic flows. However, BE is guaranteed the link bandwidth exceeding the two thresholds, but the queueing disciplines do not assure any performance on delay and jitter. As EF and AF flows require QoS, we think that this kind of traffic needs a fixed route from source to destination, which appears to them as a virtual leased line [11]. For this reason, from now on we will indicate these two categories as Connection Oriented (CO) traffic. Routing of CO connections is a priori fixed, so that the BB can perform a CAC on the bandwidth available on each traversed link and, eventually, deny access to the network. Thus, we have already identified a first task for our BB. Since we wish to maximize the network throughput, we use a simple min-hop metrics for CO, to reduce the number of links traversed. Otherwise, the whole architecture is suitable for more advanced routing metrics [12], especially those based on aggregation and multi-parameters metrics [13]. For BE, instead, we choose a cost equal to the reciprocal of the residual available bandwidth left from CO connections. In this case, paths vary dynamically as network load changes over time. Now, the issue is how to share link bandwidth among the three competitive classes. Obviously, CO traffic is critical, because it is thought of as a high revenue one. But we would like to give some form of protection to BE, too. To do this, we assign a cost to each class (as explained later), and try to minimize some given cost function. Nodes collect data on the incoming traffic load, then the BB gathers all these data and computes a new allocation for all links. Finally, it sends the EF and AF thresholds to each node for its output links. This is the second task demanded to the BB. To complete the description of our architecture, let us note that a third task of the BB is to collect information about domain ingoing/outgoing traffic from the nodes, and to act as a node for the BB of an upper level. 3. Simulation framework Global network allocation is not a simple task; so, to reduce complexity, we perform resource allocation separately for each link. On the other hand, bandwidth is a resource of the single link, and this somehow supports our choice. Note that our BE metric depends on allocation, but allocation in its turn depends on the paths selected by the routing algorithm. A congested link at a certain time instant can become an empty one after allocation due, for example, to the discovery of a new optimal route for BE traffic. Optimizing allocation separately on each link in the presence of such routing oscillations is very hard: changing bandwidth allocation results in modifying

4 routing behavior. Our approach is to perform subsequent allocations until both allocation and routing possibly converge. Let us now analyze in more detail how the BB works. We have two distinct phases: network simulation and allocation. Note that only a flow level is considered, in order to speed up the simulation. Source-destination pairs of two types are identified in the network: CO peers and BE peers. The former generate either EF or AF traffic, while the latter only BE traffic. CO flows are generated with exponentially distributed and independent interarrival and service times. Suppose that information on the traffic intensities of these flows is available at the BB (i.e., they are measured by each node and transmitted to the BB) and varies slowly in time. When a flow attempts to enter the network, a path through the network is computed, and a counter of total accepted flows is increased on every link traversed. If a path cannot be found (i.e., the flow is refused, as no resources can be allocated by the acceptance control), a phantom path is anyway selected, in order for the nodes that the connection would have traversed to keep track of the request. In this way, the whole offered load contributes to the decision on the sharing of the links bandwidths in the allocation phase. Thus, for each link, the offered CO load is the total number of flows (real or phantom ) traversing the link. For BE traffic we follow a different approach. We think of CO traffic as prevalently real-time, and therefore relying on UDP or RTP. Applications of such type usually transmit at constant bit rate, or at most adapt their rate dynamically (e.g., if they want to be TCP-friendly ), but within a limited range. On the contrary, BE is the plain current Internet traffic, carried by TCP. TCP modeling is an open issue in today s research, and it is a quite difficult task [14]. Some authors have proposed various models, even rather complicated [15]. Our aim is to reproduce some peculiar characteristic of TCP behavior without applying complex models; details on our approach are given in section 4. Given the model and the sharing rules, on each link, we will determine the average bandwidth occupied by the BE traffic, to be used as one of the inputs to the allocation procedure. Simulation and allocation alternate in our system. Through simulation we generate network traffic and evaluate offered load on every link; successive allocations try to share the available link bandwidth among the different traffic classes. If allocation converges, network resources are optimized, and the BB can set new thresholds on all nodes. When variations on the incoming traffic are learned at the nodes, the BB is notified and starts a new allocation procedure. 4. Models of TCP behavior As already stressed, we adopt a very simple model of TCP (our goal is not to evaluate TCP performance, but rather to capture the aggregate behavior of connections between an ingress-egress router pair for control purpose). Basically, our idea is that connection durations in a simulation depend on network load. We can statistically generate the amount of data to be transferred over a connection, but not connection durations [14]. The effective duration of a connection is actually determined by the congestion control mechanisms of TCP and overall network conditions: the numbers of CO connections of every class determine the bandwidth left for BE traffic, and the number of TCP connections influences the way the remaining bandwidth is shared. Because of this, we think of each BE peer as an infinite queue where session requests arrive; interarrival times are exponentially distributed. Each request refers to the transfer of a given amount of data, whose size p follows a Pareto distribution:

5 f p ( P)=α α P ( 1+α) (1) Fixing α>1, the mean of this distribution is finite and equal to: E{}= P α (2) α 1 In our tests, the mean size of bursts is chosen equal to 2Mbits. Such arrivals correspond to the amount of data to be transferred; the queue output rate is computed accordingly to network load. Specifically, we start from the principle that TCP connections on a single link share the available bandwidth equally. With this hypothesis, the problem is similar to that one of finding appropriate flow rates to achieve fairness among different flows traversing the network [16]. The basic idea consists of simultaneously increasing the rates of all connections until one link is filled or a maximum transmission window is reached (congestion window or advertised window [18]). This means that all flows sharing that link cannot further increase; we continue by rising all the others. This is repeated until all flows cross at least one congested link and can no longer increase. This model neglects some important features of TCP, such as slow start, error recovery, etc. However, we remember that we are interested in simulating TCP data flowing across the network to calculate how long a connection takes to be served, and not in carefully modeling such protocol. More formally, let us define: k the algorithm s step; C a the capacity of link a; r p the rate of connection p; P the set of all connections; A the set of all links; P k the set of connections not yet saturated at step k; A k the set of links not yet saturated at step k; n a k the number of flows crossing link a, a A k F a the bandwidth used on link a. Now, setting the initial conditions as: k=1; F a =, a A; r p =, p P; P 1 =P; A 1 =A. we can sketch the algorithm to determine the TCP link utilization as follows: k 1 k 1. r k = min{ ( C a F a )/n a } a A k k 1 k r 2. r p = p + r k for p P k k 1 r p otherwise k 3. F a = k rp p crossing a { } 4. A k+1 = a/c a F k a > 5. P k+1 ={p/ p does not cross any link a A k+1 & p does the exceed transmission window size} 6. k = k if P k is empty, then stop; else go to 1.

6 1 5 9 Some numerical simulations have been performed to evaluate our algorithm, by examining the TCP behaviour obtained by using the ns-2 simulator. We started with the simple network depicted in Figure 1, where 6 flows share the link from node 5 to 6. The flows that have been simulated are long-lived (the sender has unlimited amount of data to send), the maximum receiver advertised window is set to 1 bytes and link capacity is set to 1 Mbps for all links. Our tests with this network have been carried out with different queuing disciplines (SFQ and RED) and different TCP implementations (Tahoe and Reno). In such situation, our simple model shares the bandwidth equally between the two aggregates; ns results show that this is correct with RED (Figure 3, Figure 4), less with SFQ (Figure 2). The specific TCP implementation seems not to affect bandwidth sharing, as shown in Figure 3 and Figure 4. Figure 1. A network with two aggregated of flows (red and blue). Flow 1 Flow Mean Bandwidth (Mb/s) Tim e (seconds) Figure 2. Bandwidth sharing on link 5-6 with SFQ policy and TCP/Tahoe.

7 Flow 1 Flow 2 7, 6, 5, 4, , 2, 1,, Time (seconds) Figure 3. Bandwidth sharing on link 5-6 with RED policy and TCP/Tahoe. Flow 1 Flow Mean Bandwidth (Mb/s) Time (seconds) Figure 4. Bandwidth sharing on link 5-6 with RED policy and TCP/Reno. Another set of experiments with the network shown in Figure 5, has pointed out that the round trip time significantly affects TCP behavior. This is already known in the literature [2]; future work will bring into account this in improving the actual simple model. As regards Figure 6, it depicts the mean bandwidth of the two aggregates when both terminate on node 8; Figure 7 shows the same quantity when flow 1 is addressed towards node 15 and flow 2 towards node 18. Link bandwidth is again equal to 1 Mbps, and maximum congestion windows to 1 bytes. RED is used as queue management policy, and the TCP implementation is Reno.

8 Figure 5. Network with two aggregated, with different round trip time. Flow 1 Flow Mean Bandwidth (Mb/s) Time (seconds) Figure 6. Bandwidth sharing with both flow 1 and 2 terminating on node 8. Flow 1 Flow Mean Bandwidth (Mb/s) Time (seconds) Figure 7. Bandwidth sharing with flow 1 addressed to node 15 and flow 2 to node 18.

9 5. Allocation algorithm Allocating resources over the whole network is a very complex task, especially if many links are present. Furthermore, resources to be shared reside on each link. Thus, we choose to perform an independent optimization on every link, though computationally centralized at the BB. As previously mentioned, the BB knows from the single node the input traffic matrix for each flow. It runs a simplified simulation at the flow level (very fast) and collects data about offered load, in terms of number of flows trying to cross the link (CO) and average used bandwidth (BE) on every link. From this point on, it begins an independent allocation for every link. We choose a bandwidth step bw_step equal to the minimum admissible rate for CO connections. Then, the algorithm starts calculating the costs for all possible bandwidth assignment, that are generated as follows: CO bandwidth is initially set to zero, then it is increased by bw_step, until the link bandwidth is reached; For each of these values, CO bandwidth is shared between EF and AF in a similar way: the EF threshold is set initially to zero and the AF threshold to the total CO assigned bandwidth. All possible assignments are generated incrementing EF and decreasing AF thresholds by bw_step. Cost calculation CO traffic looks like traditional circuit switched traffic: there are incoming connections of a given size (peak rate for EF and mean rate for AF), competing for a limited resource. This is the so called Stochastic Knapsack problem; blocking probability can be easily calculated with an extended Erlang Loss formula [21]. Let K denote the number of EF rates (for example) and C the resource units. Connections of the k-th class are distinguished by their size, b k, their arrival rate, λ k, and their mean duration, 1/µ k. Let us denote with n k the number of active connections of class k and with S the space of admissible states: { } (3) S = n I K : b n C where I K denotes the K-dimensional set of non-negative integers, b=(b 1,b 2, b K ) and n=(n 1,n 2, n K ). Defining S k as the subset of states in which the knapsack admits an arriving class-k object, that is S k = { n S : b n C b k } (4) the blocking probability for a class-k connection is: K j=1 ρ n j n Sk /n j! B k =1 K ρ n j n S /n j! (ρ j is λ j /µ j ). Blocking rate is computed separately for EF and AF, since every category has its own reserved bandwidth and incoming traffic, independent from the other. The cost is derived from the blocking probabilities of the different rate classes: This holds both for EF and for AF. J j=1 { } CO B k (5) = max (6)

10 For BE traffic, we have a single aggregate: it is difficult to say if it has enough space or not because TCP aims at occupying all the available bandwidth. A possibility consists of deciding that the bandwidth available to BE on a link can be considered sufficient if its average utilization by the BE traffic is within a given threshold. To compute this, let q(c) be the probability to have c resources occupied in the system by EF and AF; the average number of occupied resources (UTIL) results [21]: UTIL = cq(c) (7) Thus, given EF and AF thresholds, the mean available bandwidth for BE is: DISP BE = LINKBW UTIL UTIL (8) The BB keeps track of the BE mean occupied bandwidth on the link, OCCBW, during the simulation, so we now are able to define the utilization ratio (UT) as: OCCBW UT = (9) DISP BE Starting from this, we expect that connections on the link are given enough bandwidth if this ratio is less than a given value δ. In this case we assign a null cost; otherwise we take the square of the difference between utilization and threshold δ. Summarizing, we can compute: EF ( max{, δ }) 2 G = α UT (1) This cost has a problem: it rises too fast above 1, while CO costs are upper bounded to 1. Varying α does not solve the problem; it is necessary to smooth the cost function after it reaches a given value. Thus, from (1) we get the BE cost function as: { + G / Φ G} J BE = min φ, (11) Both φ and Φ can be set to adjust the function s shape to our requirements. We found that Φ does not affect significantly our results, while they are more sensitive to variations of φ. Optimization function Several optimization function can be selected to optimize bandwidth sharing, depending on which results one is pursuing. Our aim is to equalize the costs of the classes, so that we can vary the system s fairness simply by changing some weight parameters: Equalization of costs results in minimizing (12): J { ω J, ω J, ω J } = max (12) EF EF T EF, T AF AF {} J AF BE BE AF min (13) where T EF and T AF are, respectively, the thresholds for EF and AF traffic. 6. Numerical results We have tested our algorithm on a single link and on a more complicated network. On a single link we can better appreciate the allocation choices in the presence of traffic competing on a forced path, while in the network we are able to check for oscillating

11 behaviors. Also it is possible to observe path variations implied by resource reallocation. Single link Three peers transmit simultaneously on the same link, one for each kind of traffic. The EF peer has an offered load of 15 Mbit/s, the AF of 3 Mbit/s and the BE varies from 3 to 85 Mbit/s. Link bandwidth is 1 Mbit/s, so we start from a low loaded scenario, and increase BE traffic to make the link congested. Figure 8 shows blocking probability for connections in two cases: with and without allocation. Blocking probabilities without allocation are very low, because in this case we do not apply a complete partitioning scheme on incoming connections, but instead a complete sharing, where connections are admitted until link capacity is reached. Because CO traffic has priority on BE, CO traffic is totally unaware of BE load, and it continues to experience the same blocking probability even in the presence of very high BE load. Thus, congestion bothers only BE traffic, as shown in Figure 9, where we can see how the mean queue size at the transmitter and the mean bandwidth raise as BE load increases. Finally, Figure 1 shows how EF and AF reserved bandwidths vary as BE load increases. EF with allocation EF without allocation AF with allocation AF without allocation Blocking Probability BE load (Mbit/s) Figure 8. Blocking probability for CO traffic on the single link Mean Queue Size (Mbit) Output rate (Mbit/s) Mean Queue Length with allocation Mean Queue Length whitout Allocation Mean Output Rate with allocation Mean Output Rate without Allocation BE load (Mbit/s) Figure 9. Mean queue size and output rate varying BE offered load.

12 EF AF Reserved Bandwidth (Mbit/s) BE load (Mbit/s) Figure 1. Reserved bandwidth for CO traffic. Simple network Figure 11 depicts the network used for simulations. In such network we vary the offered load for peer AF2, fixing the other parameters as stated in Table 1. Bandwidth is 1 Mbit/s for all links, except for links 4-6 and 5-6, which have only 5 Mbit/s. As Figure 12 and Figure 13 show, when AF2 traffic is low, BE2 and BE3 traffic cross prevalently link 4-6; as AF2 offered load raises up, AF traffic goes through link 4-6, the shortest path between AF2 peers. Thus, BE traffic is pushed towards another path, that crosses links 3-5 and 5-6. This allows CO traffic to traverse always the shortest path, minimizing global resource occupation. Figure 11. The test network. Traffic source Offered load EF1 15 EF2 1 AF1 3 BE1 3 BE2 15 BE3 1 Table 1. Offered load for traffic sources.

13 Link 4-6 Link 5-6 AF rate (Mbit/s) AF2 offered load (Mbit/s) Figure 12. AF mean occupied bandwidth versus AF2 offered load on two bottleneck links Link 5-6 Link Bandwidth (Mbit/s) AF2 offered load (Mbit/s) Figure 13. BE mean occupied bandwidth versus AF2 offered load on the two bottleneck links EF AF Reserved bandwidth (Mbit/s) AF2 offered load (Mbit/s) Figure 14. Reserved bandwidth versus AF2 offered load on link 4-6. Figure 14 shows bandwidth allocation on link 4-6; increasing AF2 offered load implies a larger amount of bandwidth to be reserved. Finally, Figure 15 shows blocking probability for all peers in the network.

14 EF1 EF2 AF1 AF2 Blocking probability AF2 offered load (Mbit/s) Figure 15. Blocking probability for all CO traffics in the network. 7. Conclusions We have introduced and analyzed a complete scheme for bandwidth allocation, CAC and routing in a multiservice IP network, operating in accordance with the DiffServ paradigm. The global strategy is based on a mix of analytical modeling and simulation, in order to find the optimum operating point for the network, under a given load pattern. The main objective of optimization is to obtain the capability to drive the network behaviour toward a desired operating point, which takes into account the relative importance attributed in the DiffServ environment to the different service classes. Though the work is still in a preliminary phase, and further investigation is needed to assess the performance of the scheme, in terms of stability and convergence, and to compare it with other approaches, the results obtained so far show a very promising behaviour. In particular, blocking of new flows for guaranteed bandwidth traffic can be kept at acceptable levels, without too much degradation on the performance of best effort traffic. References [1] Telcordia Technologies, WWW document. URL: [2] S. Deering, R. Hinden. RFC 246: Internet Protocol, Version 6 (IPv6) Specifications. Available online: URL December [3] R. Govindan and A. Reddy, An Analysis of Internet Inter-Domain Topology and Route Stability. Proceedings of the IEEE INFOCOM 1997, Kobe, Japan. [4] C. Labovitz, A. Ahuja, A. Bose and F. Jahanian. Delayed Internet Routing Convergence. IEEE/ACM Transactions on Networking, vol. 9, no. 3, June 21, pp [5] V. Paxson. End-to-End Routing Behavior in the Internet. IEEE/ACM Transactions on Networking, Volume 7, no.3, June 1999, pp [6] X. Xiao and L. M. Ni. Internet QoS: A Big Picture. IEEE Network, March/April 1999, pp [7] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin. RFC 225: Resource ReSerVation Protocol Version 1 Functional Specification. Available online: URL: September 1997.

15 [8] S. Hergoz. RFC 275: RSVP Extensions for Policy Control. Available online: URL January 2. [9] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang and W. Weiss. RFC 2475: An Architecture for Differentiated Services. Available online: URL December [1] J. Heinanen, T. Finland, F. Baker, W. Weiss and J. Wroclawski. RFC 2597: Assured Forwarding PHB Group. Available online: URL: June [11] V. Jacobson, K. Nichols and K. Poduri. RFC 2598: An Expedited Forwarding PHB. Available online: URL June [12] S. Chen, K. Nahrstedt. An Overview of Quality-of-Service Routing for the Next Generation High-Speed Networks: Problems and Solutions. IEEE Network, Special Issue on Transmission and Distribution of Digital Video, Nov./Dec [13] K. Lui, K. Nahrstedt and S. Chen. Hierarchical QoS Routing in Delay- Bandwidth Sensitive Networks. Proceedings of IEEE LCN 2, Tampa (Florida), USA, November 2. [14] S. Floyd, V. Paxson. Difficulties in Simulating the Internet. IEEE/ACM Transactions on Networking, vol. 9, no. 4, August 21. [15] V. Misra, W. Gong and D. Towsley. Stochastic Differential Equation Modeling and Analysis of TCP-Windowsize Behavior. Proceedings of Performance 99, October [16] D. Bertsekas and R. Gallager, Data Networks, 2 nd Edition, Prentice-Hall International Editions [17] V. Misra, W. Gong and D. Towsley. A Fluid-based Analysis of a Network of AQM Routers Supporting TCP Flows with an Application to RED. Proceedings of ACM Sigcomm 2, Aug./Sep. 2. [18] M. Allaman, V. Paxson and W. Stevens. RFC 2581: TCP Congestion Control. Available online: URL April [19] The Network Simulator ns2. Home page: [2] L. Qiu, Yin Zhang, S. Keshav. Undestanding the performance of many TCP flows. Computer Networks 37, 21. [21] K. W. Ross. Multiservice Loss Models for Broadband Telecommunication Networks. Springer, 1995.